8 Things to Pack for a SaaS Journey
For companies not natively “born in the Cloud”, getting from a Product to a Service is a journey somewhat similar to a multi-day mountain trek. There are several trails leading to the peak — some are shorter and steeper but require more skill while others will take longer, but don’t require so much experience.
In the world of SasS, some of these trails require either decomposing or rewriting your existing monolithic application. You may also start by offering your product as an image (AMI in AWS jargon), or a virtual appliance to run on public or private clouds; or offer it as a service (SaaS).
No matter which path you choose, you will end up at the peak, so here’s some stuff to pack before you leave home.
1. Microservice architecture
Much has been written on this topic already, but the main reasons to pack this include:
- Expectation of Availability: much in the same way you would react if Netflix, Facebook, or Google Maps were down for maintenance, your customers expect the same of your service
- High development speed: enormous number of interactions between the modules of a monolithic system hinders that, while microservice architecture enables this
- Quick time to production: testability and autonomy of microservices facilitate this
- Full team ownership: a team can’t really “own” a 2-million-lines-of-code module
2. Production Environment: Cattle, Not pets
A notion of a “Production Server”, which you know by name, and take tender care of, is the reason to call it a pet. Just like your dog or a cat, whom you have an emotional bond with.
Yet, when you run hundreds of instances of services — there’s no such thing as a production server. It’s just a set of faceless computers which were randomly picked to run this workload. And if one of these computers goes offline, there will be another one to take the load. That’s how we need to think of the production environment. Your software architecture must also reflect this philosophy.
3. Immutable Infrastructure
This means you don’t manually introduce changes (or patches) into the running system. Back in the days, when we had a “Production Server”, it was not a rare event to find a developer sitting with an IT guy replacing a dll or a war file to introduce a quick fix. Having multiple instances of the running code makes such an endeavor impossible. But even if it were possible, manually changing something in production creates an emotional bond with the production server which makes it really hard to replace in case of a failure.
4. Infrastructure as Code
This is truly a miracle of modern computing. You write code or a configuration or a mix thereof, and it provisions an infrastructure for you. You define what size your server needs to be, how it’s connected to its environment, which storage it has, who has access to it, and voila — you got it! You don’t need an IT guy to install, connect and configure it. You don’t even deep knowledge of how to make it work — you just define it — and there it is.
5. Automate Everything
It’s easy to see why given multiple instances of microservices, building an infrastructure out of thin air, deploying your code into it, and orchestration of this all must be automated.
You must be able to develop the ability to build, destroy and alter the underlying IT infrastructure as well as to automate deployments, upgrades and rollbacks of your code. Your code needs to run through a series of automated tests before being deployed. After everything is deployed, you must have a way of knowing if everything is running smoothly. You’ll need to build mechanisms which will notify you when things misbehave — be it an increased CPU load, an application error, or a high latency of a response to a user.
6. Autonomous Team
Once upon a time there were:
- a Development team (or teams) who developed the code
- a QA team who received software from the Development and tested it
- an IT team who was in charge of installing, handling and caring for the Production Server
- a multi-tier Support team who was notified by the customers and handled the failures
While the knowledge and the expertise of these professions are valuable in any type of software distribution, the closer we get to the SaaS the more important it is to carry all these abilities within a single team. This team must take full ownership of a specific module and handle its whole lifecycle, starting from the requirements, architecture, development, testing, deployment, and maintenance. You built it — you run it.
7. T-Shaped Expertise
An autonomous team must be able to execute a wide range of tasks. Given the team is finite in size, each team member will need to have multiple abilities. A definition of a “T-shaped” engineer is someone who has deep knowledge in one specific area, but also has some knowledge in many other areas. For example, a T-shaped engineer may be an expert in Java with some knowledge in networking, security and cloud.
In this case, engineers highly specialized in one domain and deficient in others, would be less desirable to the T-shaped engineers since they can only play a limited part of the team’s responsibilities.
8. DevOps
DevOps is a culture which incorporates and facilitates the principles above. It starts with understanding that the engineering team must carry the burden of multiple specialized teams, including Development, IT, QA, Support and Operations. It continues through the implementation of the principles such as Continuous Delivery, which drives delivering value quickly. And finally, it is about the ability of the team to embrace the T-shaped world, where everyone occasionally needs to handle tasks outside their main area of expertise.
Moving to SaaS can be a long journey, and you need to pack well. While most principles described here should be applied right from the start, the “higher up you climb”, the harder it will be for you if these principles are not followed. To continue with the analogy, you may do just fine with sneakers on your first day, but there will be a point where you deeply regret not getting the hiking shoes.
