Organisations are constantly on the lookout for new ways to build and develop software. Faster operations, cost efficiencies and increased agility can help businesses in almost any sector of the economy gain a vital edge in the market.
As running applications in the cloud have become central to how businesses operate, a new set of terms have been coined to describe the engineering approaches. However, these labels often sound similar, and instead of creating clear paths for companies to plot a route to a cloud-based future, they can actually make understanding the way ahead more complex.
Ultimately, understanding these terms and how, and if, you should apply them to your business can help you create and maintain secure and agile applications - and tap into the bigger business rewards.
Demystifying the jargon
Three of the key terms in the industry are ‘being cloud-native’, ‘developing 12-factor applications’ and ‘adopting a microservice architecture’. All three are more about how your applications are built and run, rather than where they are run (a common misconception with the term cloud native). The bits that they have in common, however, are where the real value is.
What these phrases really mean can be summarised as:
- Cloud native refers to an approach to building and running applications with a view to remove or dramatically reduce the cost of change/tech debt.
- 12 Factor applications explicitly declares 12 important factors to take into consideration when writing your applications.
- Microservice architecture describes how to build and run your application as a collection of services that are organised around your business services.
What a best practice business looks like
Following best practice is essential for building secure and long-term projects. It will give you the confidence that your applications can handle whatever challenges the future may throw at it, and keep long term costs from spiralling out of control.
There are five key principles for best practice that we recommend:
1. Building small, discrete services
Developers being responsible for writing small discrete services has numerous benefits, most of which are about managing complexity. Smaller services mean developers can grasp the full functionality of the service at speed, allowing them to start iterating and providing business value much quicker than maintaining large and usually more complex monolithic applications.
This type of approach also enables a team to more easily deploy independently, automate testing, change the underlying technology without affecting the overall service as well as being able to fail independently, enabling a much simpler route cause analysis.
Scalability defines how well your service handles load. It’s key to ensuring you aren’t running under or over resourced applications which in turn, would have a massive impact on how many users you’re able to serve or how much you’re spending in terms of cloud infrastructure costs.
Broadly speaking, you can scale your service to handle increased load, in one of two ways. ‘Up’ - giving an application more resources, or ‘out’ - increasing how many instances are dealing with the load.
Resilience is key to ensuring your services are able to operate normally in the face of faults and challenges. This normally refers to challenges caused by external factors, such as instances being removed from service, or targeted attacks to your service but could also be down to misconfiguration of components in the makeup of your system.
Observability can be an incredibly difficult thing to administer, especially if you have written your microservices in a range of languages. However, a platform capability, with an understanding of traffic flow makes it a lot easier to implement.
Observability can help analyse your entire system for potential faults and changes in user behaviour through a combination of monitoring, alerting, tracing, log aggregation and analytics.
A well observable system will not only allow you to mitigate potential faults, avoiding service downtime entirely, but also enable a new level of innovation as you understand user behaviour and are able to ask questions of your system in a consistent manner.
Robust Automation touches upon most of the terms noted above, as well as introducing new principles to improve the overall security posture of your service, these are:
- Paranoia - developers assume users are able to break out of their code, or that their code will fail
- Stupidity - developers assume users will try incorrect or malformed inputs
- Dangerous implements - Users should not be able to gain access to libraries, data structure or pointers to data structures, avoiding the risk of users being able to find loopholes in their service.
- Can’t happen - Over time, when code is modified developers may introduce cases that shouldn’t be possible.
A developer or operations engineer should think how each of the areas above should be handled and mitigated to guard against erroneous use and external threats, generally through testing to build robust, well automated services.
Balancing the risks and the rewards with Kubernetes
Kubernetes has rapidly become central to ensuring your applications are able to follow best practice principles. Introducing containers to package applications, encourages the principles of the microservice architecture of having a single purpose, lightweight and portable application. Kubernetes addons allow you to scale your application, using horizontal pod autoscaler (out) or the vertical pod autoscaler (up) in combination with the cluster-autoscaler to automatically scale the underlying infrastructure, giving you the elasticity you need to scale your application to deal with demand, whilst keeping infrastructure costs to a minimum.
Becoming a cloud native business has some cons, but on almost all counts the pros will outweigh any risks.
While those being key components and benefits to becoming a cloud-native organisation, writing 12-factor apps in a microservice architecture can be a huge undertaking. However, the efficiencies that it brings to your organisation and teams are worth the effort. Overall, it will allow your services to be developed with a lower cost of change/technical debt, improved speed of delivery, and provide a more reliable service to your users.
Jay Keshur, co-Founder and COO, Appvia