Evolução do Ecossistema de Startups: um Modelo de Maturidade

“Ecossistema de startups de São Paulo ainda é pouco maduro”, diz autor doutorado no tema

Daniel Cukier, doutorando do IME-USP, estudou as startups de São Paulo, Nova Iorque e Tel Aviv e criou método para avaliar maturidade do ecossistema. Defesa do trabalho será no Campus do Google

Os chamados ecossistema de startups não são novos.  Alguns desses centros tecnológicos compostos pela relação entre  empreendedores, universidades, empresas, incubadoras, aceleradoras, fundos de investimentos, entre outros já existem há mais de 50 anos, como no Vale do Silício, um dos mais antigos do mundo e de onde saíram gigantes da tecnologia como Google, Facebook, Apple.

Com o avanço da internet, dos dispositivos móveis e dos serviços de nuvem, as startups se tornaram assunto da moda, fazendo surgir novos ecossistemas ao redor do mundo. “É um desafio comparar centros de inovação, pois têm graus de evolução e maturidade diferentes. Aprender com os exemplos é importante, mas sem imitá-los. Cada ecossistema tem que focar nas suas qualidades e necessidades”, diz Daniel Cukier, aluno de doutorado do grupo de empreendedorismo digital do Departamento de Ciência da Computação do Instituto de Matemática e Estatística da Universidade de São Paulo.

Ele passou os últimos 6 anos analisando startups de vários ecossistemas, entrevistando dezenas de empreendedores em Tel Aviv, São Paulo e Nova Iorque, além de outros agentes importantes como fundos de investimentos, gestores de universidades, aceleradoras, incubadoras e gestores públicos.

O doutorando desenvolveu, junto com seu orientador, Prof. Fabio Kon, uma metodologia para avaliar o grau de evolução de cada ecossistema em 4 níveis: (1) Nascente, (2) Evoluindo, (3) Maduro, (4) Autossustentável. A tese “Evolução do ecossistema de startups: um modelo de maturidade”,  coloca Nova Iorque e Tel Aviv no grau 4 de evolução, enquanto São Paulo é avaliado com nota 2. Para ser considerado “autossustentável”, o ecossistema precisa de tempo e muito trabalho para amadurecer.

As principais sugestões de melhoria para São Paulo apontados pela pesquisa são:

  • Criação de mais eventos sobre empreendedorismo

  • Fomento à educação de técnicas de empreendedorismo nas universidades

  • Aumentar a prática de compartilhamento de casos de sucesso

  • Diminuir o risco para empreender, com políticas tributárias diferenciadas para startups e menor burocracia

  • Aumento do investimento em startups tanto de agências de fomento e instituições públicas quanto de grupos privados.

A metodologia criada permite também analisar outros importantes ecossistemas brasileiros como Campinas, Belo Horizonte, Florianópolis, Recife, identificando lacunas e propondo ações práticas e personalizadas que possam resultar em melhorias significativas e levar esses ecossistemas ao próximo nível de desenvolvimento.

A defesa de doutorado será apresentada no dia 2 de maio de 2017 no auditório do Google Campus, um dos mais importantes espaços para empreendedorismo da capital. “Faz muito sentido que a defesa de um trabalho que reflete, entre outras coisas, sobre o envolvimento da universidade com o ecossistema empreendedor, seja feita em um espaço que respira inovação, como o Google Campus ”, disse o orientador, Fabio Kon.

A banca examinadora terá alguns nomes de peso da academia, como Ary Plonsky da FEA-USP, Marcelo Nakagawa do INSPER, Paulo Lemos da UNICAMP, além da presença internacional da pesquisadora especialista em startups Xiaofeng Wang, da Universidade de Bolzano, Itália.

O evento é gratuito e aberto ao público em geral. Inscrições com vagas limitadas pelo link http://bit.ly/defesa-doutorado

Horário: 2/5/2017 – 14h

Local: Google Campus – Rua Coronel Oscar Porto, 70 – Paraíso

 

18049858_10155166631881250_1545781179_o.jpg

 

Valsa do Empreendedor


Eu vou montar um negocio, já pensei na ideia e sou programador
Tenho uma amiga designer, registrei um domínio, contratei servidor
É um momento novo na minha vida de trabalhador
Chega de ser empregado
Meu destino agora é ser empreendedor

Empreendedor, empreendedor,
O meu destino agora é ser empreendedor

Ter uma empresa é bacana,
Não tem chefe, não tem grana,
Basta um computador
Uma garagem já serve
Uns amigos, umas brejas e programar com ardor

Vou inovar, inventar, sei que vou encontrar um bom investidor
Chega de ser empregado
O que eu quero agora é ser empreendedor
Empreendedor, empreendedor,
O que eu quero agora é ser empreendedor

Minha startup deu certo,
Fiquei rico, sou esperto,
Já virei um mentor
Falo as besteiras pro povo
E eles ouvem, acreditam
Que eu sou seu salvador

Mas eu sou só um ser humano salvando a si mesmo entendendo a dor
Sei que empreender é uma arte
Tentando faz parte
A sorte o amor

Empreendedor, empreendedor,
O que eu quero agora é ser empreendedor
Empreendedor, empreendedor,
O meu destino agora é ser empreendedor
Empreendedor, empreendedor,
O que eu quero agora é ser empreendedor
Dor, dor, dor, dor, dor, dor, dor
O que eu quero agora é ser empreendedor

How I reduced 48% of my cloud cost by using Google Cloud preemptible instances

Google Cloud Platform has an amazing feature that few people use, partially because it is unknown, but mainly because it is very difficult to set up a system architecture that allows you to use. This feature is preemptible instances. How does it work? Simple: you have a virtual machine like any other, except that this VM will shutdown unexpectedly within 24 hours and be eventually unavailable for short periods. The advantage: this preemptive instances cost less than 50% compared to the ordinary machine.

Usually, people use this kind of machine for servers that run workers or asynchronous jobs, a kind of application that does not need 24/7 availability. In my case, I could use the preemptible instances for my internal API, an application that do need 24/7 availability. This internal API can’t stay offline, so the way I solved the unavailability problem was by running many servers in parallel  behind a haproxy load balancer. So, in basically 3 steps I could reduce my API infrastructure cost by 50%.

Step 1 – Setup the client to be fault tolerant

My code is in Scala language. Basically, I made the client to repeat a request when it eventually failed. This is necessary because, even if the API machines are behind the load balancer, the load balancer takes some time (seconds) to realize that a specific machine is down, so eventually it sends some requests to unavailable machines. The client code snippet is:

def query(params, retries = 0) {
  val response = api.query(params)
  response.onSuccess {
    codeForSuccess()
  }
  response.onFailure {
    case x => {
      LOG.error(s"Failure on $retries try of API request: " + x.getMessage)
      Thread.sleep(retries * 3000) //this sleep is optional
      query(params, retries + 1) //the could be a maximum number of retries here
    }
  }
}

Step 2 – put all servers behind a load balancer

I created a haproxy config file that I can auto-update based on a list of servers that I get from the gcloud command line. Here is the script that re-writes the haproxy config file with a list of all servers that has a specific substring in their names:

#!/bin/bash
SERVER_SUBSTRING=playax-fingerprint
EMPTY_FILE=`cat /etc/haproxy/haproxy.cfg |grep -v $SERVER_SUBSTRING`
NEW_LINES=`gcloud compute instances list |grep $SERVER_SUBSTRING | sed 's/true//g' |sed 's/ [ ]*/ /g'|cut -d" " -f4|awk '{print " server playax-fingerprint" $NF " " $NF ":9000 check inter 5s rise 1 fall 1 weight 1"}'`
echo "$EMPTY_FILE" >new_config
echo "$NEW_LINES" >>new_config
sudo cp new_config /etc/haproxy/haproxy.cfg
sudo ./restart.sh

The restart script reloads the haproxy configuration without any outage.

Step 3 – create an instance group for these servers

By creating an instance template and an instance group, I can easily add or remove servers to the infrastructure. The preemptible configuration is inside the instance template page in google cloud panel.

  1. Create an instance template with preemptible option checked
  2. Create an instance group that uses that template

Screen Shot 2016-05-04 at 10.40.58 PM

 

Screen Shot 2016-05-04 at 10.41.18 PM

One very important warning is that you need to plan your capacity to allow 20% of your servers to be down (remember that preemptible instances eventually are out). In my case, I had 20 servers before using the preemptible option. With the preemptible on, I changed the group to 25 servers.

Before After
Servers 20 24
Cost per server $0.07 $0.03
Total cost per hour $1.4 $0.72
Total cost per month $1,008 $518

Price reduction:  $490 or 48.6%

Graphs of server usage along 1 day (observe how many outages there are, but application ran perfectly ):

Screen Shot 2016-05-04 at 11.12.36 PM

Go up to the cloud

Prioritizing existing cloud solutions for features non-core to your business

When Daniel started to work in Elo7, the company website infrastructure was installed in two bare metal servers. Local SMTP server application was responsible for mail delivery. Server logs were stored in local drive. Managing and scaling bare metal servers was difficult, so everything was migrated to cloud instances. The mail delivery was decoupled from the application server and migrated to a service provider. Server logs were also migrated to a cloud PaaS, so developers would not need to log in the application servers to search in log files. These and other changes to the cloud lead to a lower cost and more flexible systems architecture, enabling the Startup to grow fast and solid.

Startups do not have time to build their own physical server infrastructure. They need to focus on their own product or service development. Nowadays, there are a lot of services that provide almost everything a Startup
needs to setup its business online. There are hundreds of offerings on Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS) layers. Moreover, most providers offer very low costs for low usage, as well as free tiers for beginners.

Today it is possible to build a technology company just by sticking together existing solutions. There are thousands of different Software as a Service (SaaS) platforms, most of them offering free tier for small companies
to solve a wide range of problems a company has, from file sharing applications to accounting software and communications tools. Almost everything is available freely online.

Software running into production is much more complex than running on developers machines. There are many cloud providers that offer simple solutions to deploy software in a mater of a mouse click, without needing any knowledge on system administrations. These Platform as a Service (PaaS) environments save a lot of precious time for startups, which in the beginning don’t have any specific requirement that justifies building its own
infrastructure.

Building a physical server infrastructure is hard, time consuming, and expensive. Developing commodity software is also a waste of time. Startups do not have time to spend on tasks other than their core business.

Startups usually have few software developers to do the entire job. It is impossible for a small team to be competent in all technologies. In a software startup, its product codebase is the most important place developers should spend they hours, learning about the business domain and creating inexistent and innovative solution to the startup customers. Moreover, every line of code deployed into production increases the maintenance costs. If developers spend time maintaining software non-core for the business, they have less time to work on core functionalities. It is a matter of cost benefit between building and buying. Building software non-core to your business will make you loose focus from your customers.

Therefore:

Use ready-made infrastructures over building your own solution. Prefer SaaS to PaaS, prefer PaaS to IaaS, prefer IaaS to ‘building your own infrastructure’, except for features core to your business.

The more non-core software you delegate to the cloud, the more time your team will have to work on what really matters: your customer. When you spend more time on your business software, you deliver more value and learn faster from your clients. By continuously delivering software to your customers you are bound to become competitive and profitable.

If you need a communication tool to keep the startup remote team together, you can use HipChat or Slack. For documents and spreadsheets creation, there is Google Drive, Microsoft Office 360. Virtual machines infrastructure
monitoring can be achieved with New Relic. Systems log processing and analysis can be done with Loggly or Splunk. Do remote pair programming with Screen Hero.

Most of these SaaS, PaaS and IaaS solutions were a startup someday. Off course if your startup product is a cloud system, developing a cloud service is core to you, so you won’t delegate these core functionalities to third
party companies. But even cloud service providers use third party software. IaaS companies use SaaS. SaaS companies use IaaS, and so on. The DevOps for Startups pattern can help you to choose the right balance between different cloud layers. A bad consequence of choosing the wrong cloud solution is that you can get stuck to a specific provider, so take care, preferring standard and replaceable solutions instead of proprietary hard to migrate architectures.

How to attract talents to your Startup?

Long term purpose instead of money

Differentiate from big companies to attract talents.

Work tableWhen I started Playax with my partner Juliano, we did not have money to pay high salaries for tech talent in São Paulo, one of the most expensive cities in Brazil. Our startup was a high-tech innovative platform in the music industry, so we needed the best developers to create complicated algorithms. On a first try, we offered bellow average salaries, but even if some developers were interested in the company’s challenges, they did not accept the job. When we started to offer equity, we attracted exactly the people we wanted to our team: people with passion and long-term commitment with the company. Moreover, people willing to give up high salaries in exchange of being part of the company’s construction and purpose. 

Continue reading

Comparing cloud services for Startups

nuvemEvery Startup that has services online needs a cloud provider. Startups do not have time to build their own physical server infrastructure. They need to focus on their product or service development. But what cloud to use? There are so many different options, and CTOs do not have time to test each one of them. Maybe this post will help new Startups  to choose between all cloud providers available.

The experience that I had with Playax was not typical, for two reasons: the first was that I have a lot of experience working with cloud. After working at Locaweb for 5 years, and developing software for internal cloud team, I spent one year in my PhD studying cloud services. The second reason is that Playax product is highly dependent from cloud. We are a BigData company. We needed a big infrastructure from day one. Our MVP needed a lot of cloud resources to be useful to our customers. Most of Startups do not need that much infrastructure, at least not before it starts growing fast.

Continue reading

Funk Cavala (Go horse)

Esse funk explica a metodologia extreme go horse, uma maneira incrível de desenvolver software:

Meto meto meto meto
Meto metodologia
Enfio um if igual cavalo
No programa faço orgia

Vai cavala, Vai cavala,
Enfia um if e manda bala

Sou programador responsa
Fazer teste é pra coxinha
Só otário refatora
Meto um if e amacio

Qualidade é o meu ovo
Vou fazer bem rapidinho
Compilou já tá valendo
Faz commit e sai sorrindo