Kubernetes is generating a lot of buzz at the moment, enough that it’s becoming the next ‘magic pill’ that will fix everything. Although, in the same way that previous buzz waves have gone, focusing on a single technology isn’t always appropriate, so we’re taking a step back and asking what is cloud native, and is your business ready for it?
It is generally understood now that moving a workload to a virtual machine on a public cloud platform isn’t always the best approach. A single virtual machine running in this way still needs to be managed, just as if it were in your own datacentre. In the same way, building a traditional application into a container and running that container on a Kubernetes platform isn’t really an improvement.
Before an application is migrated onto a Kubernetes platform it should be refactored to make the most of the platform, to make it cloud native. This means that both the infrastructure and the application need to conform to certain operating models before they can be considered cloud native.
What is not cloud native?
To understand what cloud native is, let’s first start with what it isn’t.
- It is not running your existing servers in the cloud. Renting a virtual machine from a public cloud provider does not make your infrastructure cloud native. The processes to manage these virtual machines is often no different to managing them if they were in your datacentre.
- Running your applications in a container does not make them cloud native. In fact, using a Continuous Delivery pipeline does not mean that your application has been designed and developed to take advantage of cloud computing. Even if you take your containers and hand them over to a container orchestrator, like Kubernetes, it doesn’t mean they’re cloud native. This just means your containers are scheduled to run on a Kubernetes cluster. Not to say you won’t benefit from this, but it’s not the whole picture.
- Infrastructure as Code is not cloud native. While this is a big step in terms of mindset for the infrastructure team, and can bring huge benefits, it still falls short of being cloud native. Often the use of configuration tools is dependent on humans, which is a huge limitation in terms of scale.
With this in mind, what IS cloud native?
What is a cloud native application?
At its core a cloud native application is built to take advantage of the cloud computing model. This means that it runs on a platform with no regard for operating systems, hardware or the stability of what it is running on. As it shouldn’t rely on these attributes, it should be portable between environments and the resiliency should be built into the application, with each component loosely coupled with another. Agility should be designed in from Day 0, allowing the application to be inherently scalable and easier to develop individual components quickly.
An approach that is often cited as embodying these principles is building your application as microservices. This is breaking down your application into individual components, each performing a specific task or function. This enables each component to be scaled independently, which is useful as your web front-end will generally have different resource requirements to your database for example. Often the term microservices is used interchangeably with containers, this doesn’t have to be the case. A cloud native application also does not need to be a container, the packaging method doesn’t change the way the code is written.
Splitting applications into loosely coupled services and modules often leads to the application becoming easier to maintain, and inherently more scalable, as each of the components are separate.
So, cloud native infrastructure is a requirement to run cloud native applications, but what is cloud native infrastructure?
What is cloud native infrastructure?
Cloud native infrastructure is abstracted away from the consumer and is API driven. This means that the complexity of the infrastructure is hidden away from the consumer and enables more complex use of the technology without necessarily needing to understand the underlying layers.
Cloud native infrastructure is Infrastructure as Software, rather than Infrastructure as Code. The key difference here is that software will run continuously, without intervention, and make the relevant changes to enforce the defined representation of infrastructure.
Cloud native infrastructure enables the consumer to make declarative statements about how an application should look and the infrastructure handles the changes needed to make this representation a reality, such as creating the required components.
A great example of this approach is Kubernetes. You create an application deployment on Kubernetes and describe what you want – for example, nginx web service, 5 instances – and Kubernetes will make it so. If one of those instances becomes unhealthy for any reason, Kubernetes will create another. It’s important to note that Kubernetes can be used in a cloud native way, but it can also be used in a non–cloud native way.
Ideally cloud native infrastructure will be self-service. This is a huge enabler to increase the velocity of development teams. This does not mean that infrastructure teams are no longer required, far from it. They would still be required in a consultative capacity to ensure development teams understand what is required and how they can utilise what they are given appropriately.
For all it’s in the name, cloud native infrastructure doesn’t need to be in a public cloud. You should be prepared to build a cloud internally with a clear understanding of why you are building your own and not simply consuming an already existing product.
Now we’ve got to a better understanding of what cloud native infrastructure is and that it’s required for cloud native applications, what about the business processes and culture?
What is cloud native practice?
While cloud native applications and infrastructure are all about the technical detail and processes, humans are needed to meld the flows into a highly functional operation. These humans need to work with each other, both software and infrastructure engineers. A commonly used term, DevOps, can be used to describe the culture of the organisation.
DevOps means different things to different people. Fundamentally it is teams of multiple skillsets working closely together to deliver business value. It moves away from ticket queues and fences to throw things over. It moves towards product focused teams where each team will build and run the products they’re responsible for.
Another key factor is to make application releases ‘dull and reliable’. Once this is in place it encourages frequent releases. Both of these combine to make the risk much lower and enables faster user feedback. Once in this fast feedback loop, iterative changes can be made quickly.
The next step along the journey, once application releases are ‘dull’, is to look towards a Continuous Integration / Continuous Delivery (CI/CD) methodology. This enables applications to be developed, tested, and released on an automated basis.
As a business you need to have a supportive culture where teams aren’t afraid to experiment and fail. Failure needs to be embraced as a learning experience, not a finger pointing exercise.
The best place to start is by defining what problem you’re trying to solve. If there is a problem with the business process or the culture of the company, getting Kubernetes or becoming cloud native is not going to fix anything for you. It will add a layer of complexity that you’re not in a position to derive value from.
If you’re confident your teams are operating at a level where they can take full advantage of cloud native, you need to think about what requirements you have of the infrastructure.
Are you looking for:
- Workloads restarting when they fail?
- Service discovery?
- A self-service platform?
These are the types of questions that you should look to answer before looking for a solution – Kubernetes might be it, it also might not be.
Finally, moving to a cloud native model isn’t going to be the right architecture for all your applications, some applications may be better served staying as monoliths, or there could be a use case for a hybrid model. Potentially some components of your application need to scale more or have a greater velocity of feature enhancements. These components could be spun out into microservices as part of that process.
Accelerate your success with Xtravirt
As a cloud and digital transformation company we can help you unlock the full power of technology to achieve your business outcomes. Xtravirt hold all VMware Master Services Competencies and Partner Solution Competencies including VMware PKS. We have a wealth of experience and expertise in developing and designing modern application solutions. Contact us to see how we can help.