Amido is a technical consultancy specialising in customer identity, search and cloud services.
Gray writes as follows…
Companies are attracted to cloud native applications because it takes them further away from the ‘bare metal’ maintenance associated with traditional infrastructures; for instance installing software packages and managing updates etc.
When companies decide to go cloud native, you can essentially move into a serverless architecture and can choose to go with a managed service provider like Azure App Service or AWS Elastic Beanstalk/ECS. By doing so, you remove the overhead of having multiple teams –a team in-house writing code to create what you the application or solution, and, another team making sure it operates well, and instead have a number of skilled workers who can develop and operate simply by using platform tools.
Additionally, you don’t need to hire as many specialists to implement more complicated elements of data processing – i.e. data pipelines or machine learning algorithms; these are all now drag and drop interfaces so developers can focus on the insights the data brings, rather than the infrastructure and algorithm build.
What changes in cloud native?
So what elements of programming architecture change when you go cloud native?
It can be difficult to remain vendor agnostic when you embrace some cloud native platforms because they work in very different ways and do not offer feature parity. It is, therefore, worth consulting with a technology specialist firm who are not tied into specific architectures as they’re more likely have DevOps teams that can help design a system that can be deployed over multiple clouds whilst also removing the layer associated with legacy architecture designed for monolithic applications.
When you find a trusted partner/consultant, the process to move into the cloud becomes exciting. You realise that you can introduce microservices and containers to help build services and minimise disruption when upgrades are needed, or if there is an issue.
Design for failure
An important change you need to consider when going cloud native is designing for failure.
Cloud native PaaS components usually have lower individual SLAs (typically 99-99.9% as opposed to 99.99%) which is a large increase in potential downtime. Designing for failure means being able to recover elegantly if an individual component is not responsive, or, returns an error.
Alternatively, it can also mean being more creative when designing a system which needs to have a high uptime. For example, we recently built an application which is designed for 99.99% uptime and built on some partial components which offer 99.9%. The trick is to understand the failure scenarios and design for these to ensure that the system stays responding when there is an outage of a sub component.
Microservice architecture allows businesses to manage parts of larger projects individually, avoiding blanketed updates or uploads, which can result in system delays or down-time. Their purpose is to increase flexibility throughout the business offering, allowing an enterprise to be more competitive and to become increasingly agile, as they can adapt parts of the business in isolation. This way of operating is increasingly important for today’s High Street retailers, for instance, as they look to compete with, and adapt to, omnichannel operating models.
The path to adopting a microservices architecture does not require wholesale digital transformation as it doesn’t have to be an all or nothing proposition. It is entirely possible to simply dip their toes in the microservices world without starting from scratch. This is likely to be music to businesses’ ears as they look to keep up with, and exceed, their customer’s growing expectations and demands when it comes to online capabilities.
With containers, it gives you more control over the infrastructure you are deploying. This is because you are not creating a Virtual Machine for every instance of an application, meaning deployments are rapid and the overhead of the operating system is significantly lower. This combination is powerful as it means that we can issue an upgrade/change that will take effect almost immediately, without disruption to the general use of the portal.
However, despite the advantages of containers, they are not a magic fix for all. Not every organisation can benefit from its use as some applications are not suitable for containerised deployment, and so the decision to containerise software must be considered carefully.
Our monolithic past
Monolithic applications, favoured by traditional enterprises, are not as well suited to containerisation owing to the considerably different tooling required by Microservices. Containers are far better suited for a microservices environment where large projects can be broken down into a set of manageable, independent and loosely-coupled services.
For some legacy or monolithic solutions, the decision to containerise software needs to be considered carefully. Containers are valuable when monolithic applications can be split into smaller components which can be distributed across a containerised infrastructure; but this is not to say that any application will work, just that care needs to be taken to see if it is suitable for containerised deployment.
Amido is an independent technical consultancy that specialises in implementing cloud-first solutions. We help our clients build resilience at scale, flexibility for the future and differentiation of customer experience. And, we do this while minimising business-risk and build-cost.