serverless Archives - The Software Blog

Find out what the difference between IaaS (Infrastructure as a Service) and SaaS (Software as a Service) is – and what this has to do with cloud software architecture.

Lift and shift?

You may have heard of the term lift and shift – which means you take some existing system or application that has been living happily in a data center for years, rip it out and move it over to some cloud provider. Usually the idea behind this is saving on data center infrastructure and management cost. And usually lift & shift means that you spin up the required number of virtual machines in the cloud and reconfigure their connections and backup settings. Sounds simple, but is this giving you the benefits that true cloud solutions could provide? Most likely not. VM’s are great, and they have revolutionized app and service provisioning. They have decoupled the 1:1 relationship between soft- and hardware and allowed for easy sharing of servers between different systems. And they are still going to be around for a long time. Using VM’s from some cloud provider would mean consuming Infrastructure as a Service (IaaS).

However we are in 2019, and VM’s are not the latest-and-greatest technology any more – rather look at SaaS (Software as a Service) as the new mainstream. What does that mean?

Assume you need a database to store your customer and sales data. In ancient times you would have bought a server and installed your operating system and database software. You would have planned for regular updates of your systems to cater for security patches and bug fixes. If your server broke down you were in trouble and hopefully had a disaster recovery plan that allowed for fast re-installation once the hardware was fixed or replaced. Then the VM concept entered the arena. You could just backup your entire server to a single file. Move it to another machine if required. And the virtual machine concept enabled better use of existing hardware by running several VM’s on the same physical machine – a huge step forward.

The IaaS approach

With the cloud you can now use the exact same technology but without owning any physical hardware by yourself. Just sign up with a cloud provider and book as many cloud based VM’s as you need – with size and performance as required. This approach is called IaaS – Infrastructure as a Service. But it still leaves you with maintenance work for the VM’s operating system and database. You still need to maintain and manage those setup procedures and maybe fine tune your database system parameters. If you need high availability you’ll have to set up several VM’s and manage the cluster. And if your database is sitting idle because there’s not much activity during non office hours you still pay for every single minute all your VM’s are up and running. You could do better: go and buy not the VM for the database – rather buy the database service itself! Skip that middle layer. The cloud providers offer a broad range of database services – from the classical relational DB’s to NoSQL and Caches, all fully managed, with high-availability and data backup rather simple configuration options.

The SaaS approach

This is the SaaS approach – software as a service. It will be much simpler to set up and maintain, and it will typically be more cost efficient. And easier to scale up if required. Can you do this for existing legacy software that you can’t or don’t want to touch? Probably not, at least not if your legacy software requires a specific version of database xyz with specific settings and configuration. Can you go that way for a new development? Yes of course – pick the most suitable option for your use case, and don’t forget to take a look at resource pricing before you make your choice. Your system architecture and your selection of cloud components as building blocks will have a huge impact on your future operation cost.

For many use cases the SaaS approach will be more interesting. Go that way if you can. Especially for new developments consider using SaaS over IaaS approaches, and if possible serverless over containers. The ‘lift & shift’ approach for existing applications could for many companies be the first step towards cloud based IT. However don’t stop there – at least you may want to investigate a more in-depth approach over time, where the existing application is restructured and optimized to leverage the cloud capabilities.

Check out these related articles:

What is cloud native – and what does it mean to develop software for the cloud? Find out what makes software teams life very different in cloud world. What is so special about cloud software?

Is there anything special at all? If ‘cloud’ would only mean booking a virtual server and installing the application there – then the answer would be no. However this would only leverage a small part of the what-is-possible. Hidden within the term “cloud native” is the assumption that you want to realize on-demand scalability, flexible update capabilities, low administration overhead and be able to adapt infrastructure cost dynamically to performance demands – just to name a few. Sounds wonderful… however these things won’t come all by themselves. Your software needs to be designed, built and deployed according to…

The cloud-rules-of-the-game

Huh, what’s this? First of all don’t get me wrong: there is nothing bad about having a monolithic application residing on a single server or cluster – and from development perspective this may be the simplest way to realize it. However this monolith may get difficult to extend over time without side effects, it may be difficult to set it up for high availability and to scale it with growing number of users, data, or whatever may be the reason for your scaling needs. And it may be hard to update your monolith to a newer version without impacting the users during the update.

Now consider the same application based on what is called a microservice architecture: the monolith gets split up into smaller, decoupled services that interact with each other as providers and/or consumers of stable API’s.

What makes microservices well suited for cloud applications?

Let’s assume that each service may exist not only once but with multiple instances up and running simultaneously. And let’s assume the consuming services are fault tolerant and can handle situations where a provider service doesn’t respond to a call. Wouldn’t that be cool? The overall system would be robust, and it would be very well suited to run on cloud infrastructure.

Because now if service xyz is starting to become a bottleneck you can simply create more instances of that service to handle the extra load. Or even better, this would happen automatically according to rules that you have configured up-front. This approach is called “scaling out” (compared to the old-school “scale-up” approach where you would get a bigger server to handle more load).
Next up imagine that you need to update service xyz to a newer version. One way of doing this would be to create additional service instances with the new version and remove the old ones over time, an approach called “rolling update“.
Or you decide to add a new feature to your application. Since only 2 of your 5 services are impacted you will only need to update these 2. Less change is easier to handle and means less risk.

Getting microservice architecture right is not easy, but once you have it the advantages are huge. Note that microservices architecture as such has nothing to do with the cloud as such. However both go very well together because in a cloud environment you need to be prepared to micro outages of single services anyway. You don’t really control the hardware any more, at least you shouldn’t want to. In order to be cost efficient with a cloud approach each service should be enabled to run on commodity infrastructure. From that take and pay for as much as required.

Where will your services live? – serverless vs. containers

For hosting your workers or compute loads consider a serverless approach over a VM or container based one. This basically means that you only write the service code as such and determine when and how the logic will be triggered for execution. All the rest is handled by cloud infrastructure. At Amazons AWS this technology is called Lambda, Microsoft named it Azure Functions, Google calls it Cloud Functions. The principle is always the same. There’s no virtual machine any more, not even Docker or Kubernetes containers – means less things to manage and look after, means less operations and maintenance effort. And you only pay for the execution time. If nothing happens there’s no cost. If you suddenly require high compute performance your serverless approach will be scaled automatically – if you have done your architecture homework. Serverless will e.g. require that your services are stateless, means whatever information they need to keep between two executions of the service must be stored externally, e.g. in a cache or database service. As with microservices the advantages need to be earned. Serverless will not solve all problems, but make sure your team (at least the architect) understands the concepts and can make informed decisions about its use.

Other game changers in cloud world

What else has changed in a world where dedicated physical servers seem to have disappeared? Very trivial things need to be handled differently.

There’s no local hard drive any more. If your service runs in a VM or Docker container it may feel so, but remember: in cloud world machines are cattle. A VM/container may die or disappear and will be replaced by a new one. Bad luck if you had data on a local drive of that machine. Now you’ll need to think about alternative ways for storing away your data or settings. In cloud world you may want to use a storage service for that purpose, a central configuration service, a database, environment variables… the choice depends as always on the requirements. Make sure the team knows the available cloud building blocks.
If you are a Microsoft shop: there’s no registry any more. See above comments.
For logging there are no local files any more. These would anyway not make much sense in a world where services are distributed. You’ll rather send log output to a central logging service. That will consolidate all logs of the various services in one central place, making troubleshooting much easier. There are many open source solutions for logging, our you may just use the one your cloud provider provides.
And finally the term infrastructure will get a whole new meaning in cloud world. Infrastructure still exists, but now it needs to be managed very differently. You should strive to set it up automatically, based on scripts that you can re-run any number of times. This is crucial because you will need more than one cloud system. At least you should have one for development and testing which is separate from the real one – your production system. The two environments should be as identical as possible, otherwise your test results are not meaningful and you will chase after phantom problems that are just caused by some infrastructure misconfiguration. Those scripts will set up your required cloud resources. Means you describe the infrastructure in code just as your service logic. Infrastructure as Code (IaC) is the term for that. Check out this article for more.

So what is Cloud Native after all?

Hopefully it became clear that software needs quite a few specific considerations to feel comfortable in cloud world. Which is the reason why “lift and shift” for existing legacy software is a valid approach, but won’t leverage the full cloud potential. In order to run efficiently in the cloud, software must be designed for that purpose – this is the meaning of cloud native – software that is architected and optimized for a cloud environment. For legacy software that usually means: for efficient shifting to the cloud major refactoring or even a complete rewrite may be required.

So welcome to cloud world. Tremendous power and flexibility is at your disposal. However you’ll need to architect your software with the cloud and its building blocks in mind. Decompose your application into services. Consider serverless approaches to reduce operation effort and improve scalability and availability. Focus on your domain knowledge and your specific value-add. For the basics use existing building blocks wherever it makes sense.

Check out these related articles: