A startup journey on AWS: from bare metal monolith to serverless microservices
Launching a startup is a race against time: speed and agility are the two most important abilities to win this race.
The only absolute certainty is that the bank balance declines every day. The faster the better.
– Steve Blank & Bob Dorf, The Startup Owner’s Manual
More than ever, the ultimate goal of the dev team is to focus on delivering features and business value to customers and not to spend time maintaining/scaling the infrastructure.
The goal of software development is to sustainably minimise lead time to business impact.
– Dan North
http://www.infoq.com/news/2015/04/north-kerr-complexity-code
To achieve maximum speed and agility at AgoraPulse, we rely a lot on AWS infrastructure/services and the Groovy ecosystem (which gives us a big productivity/agility boost compared to plain vanilla Java).
Last year at Gr8Conf in Copenhaguen, I gave at talk about “Running a Startup with Lean & DevOps culture”, where I shared the DevOps tools and processes we put in place to benefit from an automated delivery pipeline and deploy our apps to AWS with a single Git commit (corresponding wrap up article on Medium can be found here).
Last week, I was at London SkillsMatter Groovy&Grails eXchange 2015 to give a talk about “Serverless microservices using AWS Lambda and Groovy”.
AWS Lambda is a new AWS service that represents the tipping point of two revolutions:
- an infrastructure revolution: from bare metal servers to serverless cloud-based infrastructure,
- an architecture revolution: from monolith to microservices architecture.
During the last 10 years, those revolutions have been mainly led by big startups such as Netflix or Gilt that remain pioneers in this field.
Small startups like ours also followed that path: here is our journey!
From bare metal to serverless
Everything started in 2006, when AWS launched EC2 and S3 and initiated the cloud revolution. It was huge for startups since it provided virtual instances from a single click in the browser.
No need to call the IBM sales guy anymore to order expensive servers with huge upfront costs.
No need to wait for weeks to get them deliver.
No need to spend days installing and configuring them.
Experimenting and validating business ideas became much more accessible for startups.
In 2006, we migrated our Affinitiz (RIP) community platform to EC2+S3 and we became early happy adopters of the AWS cloud.
Most existing startups/companies follow this copy/paste path when moving to the cloud: they replicate their existing architecture on virtual instances instead of physical ones.
At that time, AWS only provided 3 services (the foundation of IaaS, Infrastructure as a Service):
- message/queue management with Amazon Simple Queue Service aka SQS (2004),
- virtual servers with Amazon Elastic Compute Cloud aka EC2 (2006),
- file storage and delivery with Amazon Simple Storage Service aka S3 (2006).
For us, it was a big relief to get rid of potential hardware issues, but we still had to configure and maintain our virtual servers (database servers, web servers, app servers, mail servers, etc). And we hated that…
During the following years, AWS added more “simple” services to make startup life even more “simple”:
- noSQL database, with Amazon SimpleDB (2007),
- SQL database with Amazon Relational Database Service (RDS, 2009),
- platform as a Service with AWS Elastic Beanstalk (2010),
- DNS management with Amazon Route 53 (2010),
- mail delivery with Amazon Simple Email Service (SES, 2011),
- cache servers with Amazon Elasticache (2011),
- noSQL database with Amazon DynamoDB (2012),
- etc.
So when we launched AgoraPulse in 2011, we were able to achieve a 99% serverless infrastructure thanks to all those services, especially Elastic Beanstalk to run our Grails apps.
Elastic Beanstalk is a great PaaS (Platform as a Service) platform to hide the complexity of servers provisioning/configuration/scaling and apps deployment. But you still have EC2 instances running there (the blue boxes) and the unit of compute/scaling/pricing is an EC2 instance.
That’s why we have been recently experimenting with AWS Lambda, the next logical evolution in AWS Compute offering. You upload your Lambda code and Amazon will take care of everything required to run and scale your code with high availability. Moreover, you only pay for the compute time you consume.
This allows you to achieve a 100% serverless infrastructure! But to benefit from AWS Lambda, a startup must have a microservices architecture, which is usually not the case, depending on its current stage in the tumultuous startup journey to success or failure…
From monolith to microservices
Almost all the successful microservice stories have started with a monolith that got too big and was broken up
– Martin Fowler
http://martinfowler.com/bliki/MonolithFirst.html
The monolith first approach described by Martin Fowler fits pretty well with the typical evolution of a startup, represented by Paul Graham’s curve.
During search mode, speed is the most important factor.
You need to test and validate your business hypothesises as fast as possible.
Monolith app is the best way to get an MVP out the door and get you to market quickly.
There are plenty of fullstack frameworks for that, focused on developer productivity. Here is a non-exhausting list, depending on your ecosystem:
- Phoenix — Elixir/Erlang, (initial release in 2015)
- Meteor — JS (initial release in 2012)
- Laravel — PHP (initial release in 2011),
- Grails — Java/Groovy (initial release in 2005, our favorite choice),
- Django — Python (initial release in 2005),
- Rails — Ruby, the inspirational grandfather (initial release in 2005)
Moreover, in practice, startups begin with a set of initial hypotheses (guesses), most of which will end up being wrong. Business boundaries are not yet well defined and you might have several small or big pivots before getting your business model right.
No business plan survives first contact with a customer
– Steve BlankWriting code is more expensive than talking to customers.
– Hiten Shah
https://hitenism.com/7-lessons-for-founders/
Thanks to customer development during the search phase where you experiment and pivot, you start to get a clearer picture of your business boundaries and you can start to gradually split your monolith into independent vertical autonomous services.
Which tech stack to use to extract and build those micro services? The easiest path is to keep the existing framework. Nowadays, most of the full-stack frameworks described above supports microservices pretty well. But you might also benefit from a polyglot tech stack and use other frameworks, designed for high performance reactive microservices (such as Vert.x or Ratpack in the Java/Groovy ecosystem) or simply use AWS Lambda.
If you haven’t done it yet, it’s also time to implement DevOps processes and tools (CI/CD, automated deployment, etc) which are required to dive into microservices.
The first rule of distributed systems is don’t distribute your system until you have an observable reason to.
– Tyler Treat
http://bravenewgeek.com/service-disoriented-architecture/
The idea is to be ready once you get to the point where you have a predictable, repeatable, scalable business model: the execution mode.
During execution mode, you must be able to support your growth and scale fast and this is where microservices architecture shines.
That’s exactly what happened to us: we started with a layered monolith when we launched AgoraPulse in 2011.
Then, we took the time to get things right in terms of service boundaries and DevOps delivery pipeline.
Nowadays, we have a very modular architecture with single concern microservices/APIs and multiple rich clients (AngularJS-based mobile and web). They can be independently developed, deployed, and scaled while allowing the right tools to be used for each.
In a startups battle for market share, would your prefer to fight with a single slow baremetal WWII bomber or with agile and fast cutting edge Tie Fighters?
100% serverless microservices, up in the clouds
Millenial developers and entrepreneurs don’t realize how lucky they are to begin their journey with such powerful, battle-tested methodologies and technologies.
It will definitely help their startup journey lead toward success instead of failure. They can directly:
- quickly start with a simple monolith MVP on a 100% serverless agile infrastructure ,
- easily evolve towards microservices during their experimentation to reach the product market fit.
To demonstrate all of that during my SkillsMatter talk, I did a live demo during which I migrated a monolith app running on my local machine (Angular2+Grails) to a 100% serverless microservices-based app running on AWS (S3+Lambda+DynamoDB), in less than 15 minutes.
This talk was a good time to experiment with AWS Lambda but also with Angular 2 (alpha 36 during the demo).
You can check my slides here:
We hope to be able to put all of this into practice with the evolution of AgoraPulse infrastructure and architecture in 2016.
Making application building simpler is the trend for 2016 and I love that!
Simplification is the Technology Trend for 2016
– Werner Vogel, CTO @ Amazon
https://www.linkedin.com/pulse/simplification-technology-trend-2016-werner-vogels
Till then, I wish you a merry christmas and if you’d like to share any idea about this subject don’t hesitate: drop me a line @benorama.
Note: we’re hiring! Are you kick-ass fullstack or front-end dev that want to work on Angular 2? You also master Java or Groovy? You must contact me to join our dream team in Paris!
If you liked this article, please hit the ❤ button to recommend it. This will make it easier for other Medium users to discover this.
