Running your applications in the cloud is no longer the future. It is the now.
Each month we talk to more and more organisations who have moved, or are in the process of moving, to cloud-based hosting and are developing their applications to run on the cloud. However, once you have decided that your next application is going to run on the cloud, there are still a lot of architectural choices ahead of you.
In this blog, I will go through some of the high-level approaches that you can take when building a cloud-native application and discuss what you need to consider when making the decision of which technologies to use. The aim of this is not to tell you which approach to use, but rather to help you consider all your options so you can decide what is best for your organisation.
The approaches we are discussing will look at the options for running your application:
- In an existing application container (such as a Java EE application server, or Spring Boot)
- On an infrastructure as a service (IaaS) platform,
- Using a cloud service to automatically provision the necessary runtime, and
- Using serverless applications.
The choice that you make for your application may be one of these, or a hybrid of them all, but understanding the options is key to being able to make the right decision.
So, the first option that we are going to consider is using an IaaS provider to supply you with "compute nodes" - virtual machines that you install your runtime of choice on to. This covers scenarios such as running your application in Tomcat, hosted on Amazon EC2. This approach allows you to make the most of your existing skills within your development and operations teams, while getting away from having to run your own data centre and maintain networks. By using cloud based infrastructure (which includes networking and compute provisioning) you move away from the constraints of a typical on-premise deployment, such as having to worry about power, UPS, network routing, firewalls etc. The responsiveness of cloud provisioning allows you to develop a truly cloud native application that scales up and down with demand, makes use of cloud storage services, and relies on cloud networking, without having to learn new languages or frameworks.
However, this approach isn’t perfect. You will still need to maintain many skills, such as operating system administration and container configuration, and it can also potentially cost more than some of the other options. This is because you are still having to provision whole compute units into your infrastructure, which may not be fully utilised.
- Re-use existing skills and framework knowledge
- Scale with demand
- Don't need detailed hardware and networking knowledge
- Can use the frameworks and libraries that you want
- Need to maintain system administration skills
- Still some over-provisioning of resources
- Need to architect for performance, resilience and failover
Automatic cloud container provisioning
The second approach to consider is using an automatic cloud provisioning service, such as Amazon Elastic Beanstalk. With these services, you upload your application to the cloud, which automatically works out what infrastructure it needs to run on and it provisions it in a way that provides load balancing, scaling, failover for you. The provisioned infrastructure is still in the form of compute nodes and load balancers, but they are created, and have all the necessary software installed, without you having to manually do so. This, in terms of automating best practices, ensures that your application meets your non-functional requirements, however it does limit you to working with a certain set of frameworks and containers.
- Don't need as detailed architectural skills
- Provision the infrastructure you need
- Don't need as many system administration skills
- Don't need detailed hardware skills
- Resilience and failover are automatically provided
- Can't use as many frameworks
- May still have some over-provisioning of resources
The third approach, and the one that most embraces the cloud, is to use a serverless architecture, such as Amazon AWS Lambda. The phrase serverless is a little bit of a misnomer, your code is still running in/on a server, it just isn't one that you have any control over. For this approach, you write your business logic and upload it to the cloud, and then pay per invocation. This can work out incredibly cheap, as you don’t need to over provision storage or compute resources for your application. You need to be aware though that this is an approach that requires some thought because you are limited to writing your application in specific languages and can only make use of certain APIs and frameworks. Serverless architectures also tend to be very event driven, which means that you need to think differently about your software architecture compared to how you would for the Object-Oriented approaches that are common today.
- Very cost efficient
- Resilience and failover are handled by the cloud
- No operating system administration knowledge required
- Only pay for execution - no risk of over provisioning
- No hardware skills needed
- Limited in what APIs and libraries you have access to
- Event driven architecture needs different design patterns
Choosing the right fit
So, as you can see, there are many approaches for building a cloud-native application, and they can all be combined, allowing different ones being used to deliver the different parts of your application. If you are still unsure, just remember that ultimately the right choice is the one that makes the most sense for you as an organisation, and that this will probably vary from application to application. Personally, I think there is a lot to be said for serverless architectures, but they do have some quite significant disadvantages that need to be considered. For example, their biggest benefit, cost efficiency, is entirely dependent on vendor pricing remaining the same.
Whilst we have not covered everything, e.g. Software as a Service (SaaS) options, and hybrids that use a SaaS application and customise or extend it, these approaches are a good place to start. Hopefully this blog has helped to encourage you to consider all the options and that, rather than just continuing to write software the same way you do now, you will be confident considering deploying it onto the cloud.