PaaS ou IaaS: Prefira ambientes híbridos

Estou super empolgado. O Google acabou de anunciar, dia 25 de março, as “Managed VMs” (http://goo.gl/yv1w6F), confirmando o que eu acredito e já digo há algum tempo: a PaaS não morreu e deve ser uma peça importante da sua estratégia de arquitetura. A consideração crucial deve ser que a plataforma *não* vai atender a todas as suas necessidades, mas em vez de descartá-la por causa disso, você tem que planejar uma solução híbrida na nuvem, usando tanto PaaS quanto IaaS.

Veja bem: não há nada de errado com PaaS

As diretrizes gerais para essa abordagem são:

1) Use PaaS o máximo que puder. Idealmente, ela deve controlar todos os HTTP requests dos usuários finais, mantendo o uso do IaaS para tarefas de backend. Lembre-se: você definitivamente deve tirar vantagem da escalabilidade facilitada pela plataforma.

2) Se possível, tente criar um MVP (mínimo produto viável) que possa ser entregue usando apenas os recursos disponibilizados pela plataforma. Fazendo isso, você terá um melhor time-to-market, diminuindo os riscos e custos.

3) Tenha em mente que você precisará usar a flexibilidade da infraestrutura em algum momento. Tudo bem! Projete um mecanismo que permita com que todos os seus servidores se comuniquem com a plataforma. Recomendo o uso de filas para isso (exemplo: Task Queues). Falando nisso, obrigado, Google, por resolver este problema para nós!

4) Comunique-se de maneira assíncrona sempre que possível.

5) Só mais uma coisa: quando precisar de algo que a plataforma não oferece, antes de correr para IaaS para resolver o problema, certifique-se de que não há outras companhias oferecendo esse recurso como um serviço / APIs. Por exemplo: você não tem que desenvolver um recurso de decodificação de vídeo em cima da sua distribuição do Linux só porque a plataforma não fornece esse serviço. Há ótimos serviços de codificação de vídeo disponíveis para uso.

Estou ansioso para testar essas Managed VMs, bem empolgado. Vida longa aos ambientes PaaS, IaaS e ambientes híbridos!

Não há nada de errado com PaaS!

Acabo de ler o artigo da InfoQ “What is going on with PaaS?“. Em resumo, ele comenta que PaaS está sendo adotada em um ritmo bastante lento e disserta sobre as possíveis razões pelas quais esse tipo de serviço está falhando e perdendo espaço para IaaS. Segundo o autor, as razões principais são: mensagem de marketing confusa, falta de maturidade e limitações das plataformas. Embora eu entenda os pontos mencionados, eu enxergo de maneira diferente e discordo de alguns argumentos listados.

Vamos lá… deixa eu comentar o óbvio aqui: PaaS é uma plataforma. Juro que algum dia eu vou escrever um artigo denominado “O Dilema das Plataformas”. Toda vez que eu vejo um desenvolvedor e/ou gerente lidando com plataformas (e não falo apenas de plataformas cloud, mas plataformas de software de maneira geral), é sempre a mesma velha história: “é limitado”, “nós compramos essa plataforma para sermos mais produtivos, está acontecendo o contrário”, “não é flexível”, “nós não sabemos como trabalhar com essa plataforma”, “deveria estar me ajudando mas está me deixando louco!” etc. Isso acontece quando desenvolvedores .Net começam a trabalhar com Sharepoint, ou desenvolvedores PHP com Drupal… e logicamente quando engenheiros de computação mudam de abordagens tradicionais de servidores para plataformas como o Google App Engine ou Force.com.

A questão aqui é: adotar uma plataforma é sempre balancear prós e contras. Abre-se mão de flexibilidade para ter outros benefícios, na maioria das vezes produtividade, time-to-market ou menor custo. Não saber lidar com os contras da plataforma vai sempre levar para soluções mais caras, lentas e custosas. Pronto: temos o dilema montado! Desista de utilizar apenas PaaS em 100% das suas aplicações. Via de regra, vai ser necessário usar IaaS em algum ponto, criando uma arquitetura híbrida. Dito isso, em minha opinião, PaaS vai sempre ter limitações e IaaS vai – pelo menos nos próximos anos – crescer numa velocidade superior. E isso é completamente normal! Não significa que tem algo errado com PaaS. Existe algo errado com Sharepoint ou Drupal porque temos muito mais projetos usando .Net ou PHP do que as respectivas plataformas?

Sobre “mensagem de marketing confusa”, eu devo concordar com o autor, mas acrescento que a expressão “cloud computing” é vaporosa (desculpem o trocadilho) para dizer o mínimo. De novo, perfeitamente normal o mundo corporativo entender IaaS (“se funciona no seu servidor, vai funcionar na nuvem”) do que PaaS. E é menos arriscado adotar computação nas nuvens começando por aí, apenas movendo servidores físicos para arquiteturas equivalentes na AWS, por exemplo. Como eu disse antes, nada de errado com PaaS aqui, demora um tempo para termos uma mudança de paradigma e cultura incorporado pelas empresas, algo mais disruptivo.

Finalmente, como desenvolver e arquiteto de software, eu vejo apenas “componentes cloud” que podem e devem ser projetados da melhor maneira possível para criar coisas incríveis com tecnologia. Isso inclui ambientes de execução super escaláveis como PaaS, clusters Hadoop gerenciados, bancos de dados replicados (SQL ou No-SQL), streams para processamentos de eventos em realtime e por aí vai, tudo na nuvem. O menu está disponível e acredito que devemos utilizar o que há de melhor para construir a nossa aplicação, com foco em atender requisitos funcionais e não-funcionais. É IaaS? É PaaS? É blablabla-as-a-service? Não importa! Quer saber? Continuo achando que arquiteturas híbridas vão imperar no curto / médio prazo.

PaaS / IaaS: Hybrid environments FTW!

I’m so happy right now! Google just announced on March 25th the “Managed VMs” (http://goo.gl/yv1w6F), confirming what I truly believe and have been saying for a while: PaaS is not dead and it should be a very important piece on your architectural strategy. The key aspect to consider here is that the platform will NOT address all your needs, but instead of discarding it because of that, you should design a hybrid cloud solution, using both PaaS and IaaS.

See: There is nothing wrong with PaaS (http://goo.gl/NWrBmf)

The general guidelines for this approach are:

1) Use PaaS as much as you can. Ideally, it should handle all the HTTP requests coming from end-users, keeping the IaaS usage for backend workloads. Remember: you definitely want to take advantage of the effortless scalability provided by the platform.

2) If possible, try to create a MVP (minimum viable product) that can be delivered using only the capabilities provided by the platform. Doing that, you will have a much better time-to-market, lower your risks and costs.

3) Keep in mind that you will need to use the flexibility of the infrastructure at some point. That’s fine! Design a mechanism to allow your servers to communicate with the platform. Task queues are a great choice! By the way, thank you Google for solving this problem for us.

4) Communicate asynchronously as much as you can.

5) Just one more thing: before jumping into IaaS to solve a specific problem, be sure that there are no other companies offering this capability as a service. For example: you don’t need to develop a video encoding feature on the top of your favorite Linux flavor just because the platform doesn’t provide such service to you. There are several great video encoding services out there you can use.

I look forward to testing this Managed VMs, really excited about it. Long live PaaS, IaaS and Hybrid environments!

Cheers, Daniel Viveiros

There is nothing going wrong with PaaS!

I just read the InfoQ article “What is going on with PaaS?“. In a nutshell, it says that PaaS is being adopted in a very slow pace and enumerates the reasons why it  is “failing” or at least losing space to IaaS vendors. The main reasons, according to the author, are: Confusing marketing message, Lack of maturity and Limitations. Although I understand his main points, I have a different point of view and I disagree with some arguments there.

First, I want to state the obvious: PaaS is a platform. Someday, I will write a post entitled “The Platform Dilemma”. Every time I see developers and/or managers dealing with platforms (and I’m not just talking about cloud platforms, but software platforms as well), it’s always the same old story: “it’s limited“, “we bought it to be more productive, but it’s working otherwise“, “it’s not flexible“, “we don’t know how to work with that!“, “it should be helping me but it’s driving me crazy!” etc. That happens when .Net developers start working with Sharepoint, PHP developers with Drupal and also when traditional computer engineers move to PaaS environments, like Google App Engine or Force.com.

The point here is: adopting a platform is always a tradeoff. You give up on some flexibility to get other benefits, most of the time productivity, time-to-market or lower costs. PaaS falls into that dilemma. You should not use it in 100% of your applications. You may even create hybrid architectures taking advantages of both worlds, together with IaaS. That said, in my opinion, PaaS will always have limitations and IaaS will – at least in the next few years – grow in a faster pace than PaaS. And it’s completely normal! It doesn’t mean that there is something wrong with PaaS. Is there anything wrong with Sharepoint or Drupal because we have many more projects using .Net or PHP than the related platforms?

Regard the “confusing marketing message”, I actually agree with that but I don’t blame PaaS for that, but the messy buzzword “cloud computing” in general. And again, I think it’s totally normal that the enterprise world gets a better understanding on what is IaaS (“a regular server in the cloud, if it works here in our datacenter, it’s going to work there”) than what is PaaS. And it also looks less risky jumping to the cloud by just moving from physical servers or traditional data centers to equivalent architectures inside AWS, for example. As I said before, there is nothing going wrong with PaaS, it takes time to shift an enterprise mindset and culture towards a more disruptive approach.

Finally, as a software architect, I see “cloud components” that can be assembled into a great architecture to build amazing things. That includes scalable runtime environments (aka PaaS), managed hadoop clusters, replicated database (SQL or No-SQL), highly scalable data warehouses and so on, everything in the cloud. The menu is open and I want to be free to choose the ingredients better suited to my challenge. It may sounds complex (and it is), but the final decision of which components I should use to tackle both functional and non-functional requirements must be made to deliver business value. Is it IaaS? Is it PaaS? Is it bla-bla-bla-aaS? Doesn’t matter! You know what? It’s probably going to be a best-of-breed of all the above.

Guidance for Combining Cloud and Social to Enable the Amazing

After a few years talking to several people inside and outside my company about the benefits of cloud computing, I’m truly convinced that the most important benefit is not cost reduction or the ability to have new servers up and running in a few minutes. Of course those are great capabilities that a real cloud computing environment can offer to you. But the most interesting goal you should pursue when using this approach is to use technology to move your business to where it has never been before, and do amazing things you couldn’t even consider doing a few years ago.

One use case I’m happy to see the market (including large enterprises) explore more and more is the enhanced customer engagement and experience achieved through a social networks + cloud combination. Although almost everybody understands how powerful this combo can be, very few are succeeding to really unleash the power of this synergy. Most companies are just scratching the surface in this area. In this article, I want to explore some ideas and useful guidance for those who want to dive into these waters.

1) Be smart, consider PaaS, avoid IaaS: when listening to social networks such as Facebook, Twitter and Instagram, you should be prepared to receive and process massive amounts of data. Do you want to design a physical architecture (load balancing, fail-over, auto-scale) to handle all the data or do you want to let companies like Google do that for you? What about private cloud? Well… I don’t even consider private cloud to be part of cloud computing. High upfront costs, limited scalability and no managed services to simplify or empower your solution. It’s more like a “virtualization on steroids” than cloud computing itself!

2) Be nice, quotas are limited: you may have an amazing idea to engage your customer but keep in mind that all social networks have limited usage quotas. Sometimes a percentage of the daily traffic (1%, for example), sometimes number of requests per hour (something like 5,000 calls per hour).

3) Be ethical, avoid spam and things like that: even restricted to your quotas, you must be aware that social networks don’t want to bother their users because… well, they actually need them to survive. So, forget about commenting on all posts in a timeline advertising your great new product or service. Your account may be suspended.

4) Be reserved, read more than you write: if you are planning just to read from the social networks, ok. But, if you are planning to write comments or posts in the same volume, you are going to be in trouble. Writing quotas are significantly lower than reading ones. You are going to be blocked unless you are whitelisted. Sometimes you won’t even have access to write APIs, unless you explain very well what your plans are.

5) Be nimble, things will change: you have just spent a lot of time using social networks’ APIs and everything is working like a charm right now. Great! But these same APIs might not work well tomorrow. Sometimes you will be notified upfront so you will have time to accommodate changes. Sometimes, you won’t. Consider using third party APIs. There are several companies specialized in dealing with this problem and they can make it transparent for you.

6) Be aware, social networking companies are not like IBM or Microsoft: if you work for a huge global company and are used to having heavy negotiations with your vendors to change their products to fit to your needs, think twice before taking that for granted with companies like Facebook or Twitter. First, they run a very complex computational grid, we have an important technical aspect to consider here. Second, they are the “millennials” of the service providers. They don’t put commercial relationship and politics ahead of technology. They also need scale and they are not ready (or perhaps it’s not interesting for their business model) to dispend a lot of attention just to make you happy. Need more quota? Need to be whitelisted? Start right now because it won’t be easy… or possible.

All that said and despite the pitfalls, I don’t think anyone can or should close their eyes to this new world. Yesterday’s hot sites are not hot anymore. People are not supposed to find your company or content anymore… you should engage them where they are, and where they are spending a huge amount of time talking to their “friends”, posting photos and videos and checking-in on social networks. Most of the time using their mobile devices, not desktops.

We need to get ready for a future where brands serve their customers best by anticipating their next move and by being ready to help exactly where they are in that moment of need. This will be the general expectation of all users. Combining social plus cloud can create that layer of intelligence never before possible. Going further, leveraging not only cloud and social, but also mobile and analytics is a key aspect to deliver such capabilities. Are you ready for this new technology landscape?