What is Cloud Native, Anyway?
Cloud native applications are giving teams the right abstractions to deploy software faster than ever before possible.
These applications are built to thrive in a cloud environment, which embraces automatic scaling and resiliency without single points of failure. But these environments can be complex to run and manage. When issues arise, software teams need clear visibility into their system to figure out what is going on.
With this in mind, we designed Humio, a log management tool, to provide such visibility for cloud systems. With Humio, users can handle large data volumes on ingest, monitor user-driven metrics, and investigate an issue instantly — right down to the single log line.
We at Humio are working hard to build a log management tool that gives users a simple and easy way to observe cloud native applications. But like our users, we are also developers building cloud native applications. Our team is eager to be an active part of a growing community of cloud natives learning and sharing what it means to call the cloud a home. This is why we participated at Cloud Native London at Code Node to learn even more about cloud native and what it means as a deployment platform.
On the surface, it’s obvious what “cloud native” means, right? But ask a hundred people and you’ll get a hundred different answers. This is a perfect example of how we in the software world come up with seemingly straightforward new phrases and then complicate them.
The team at Humio unanimously agrees that “cloud native” is too useful to become another marketing buzzword. We decided to catch up with attendees and speakers at Cloud Native London and look for a meaningful definition.
Choose your platform and build for it
Sam Newman, author of Building Microservices, opened the day’s talks by tackling the question directly. He reviewed the different ways that people define cloud native and unpicked whether they were useful.
“It’s a buzz-worthy term that has no real, good, formal definition,” says Sam. “A lot of people conflate many things in the term cloud native. In my talk, I came back down to the sub-characteristics we commonly talk about for cloud-based applications: they’ve got to be built for scale, there must be some concepts of fault tolerance, and they need to have high degrees of automation”.
Sam spent years observing and working with companies building microservices and he’s still not convinced that microservices are a required element of cloud native applications.
“Microservices can be a good way to build an application that is scalable and fault tolerant, but it’s an implementation detail”. For Sam, the key component of a cloud native architecture is to “… surrender yourself to the platform and really build for it”.
While there are attempts to build vendor-agnostic, cloud native application platforms, even they are tied to a PaaS or “underlying container orchestrator”. So to be cloud native means to build for the specifics of your chosen platform. Whether it’s AWS, GCE or a private Kubernetes cluster, each has its own peculiarities.
What does it mean to the business?
“Cool is not enough reason for doing a cloud native implementation. You need a strategic business objective for doing cloud native. A lot of people who give conference talks focus on supporting hyper scale deployments. So, supporting a very large number of users in a lot of different locations with a high degree of resilience and a good SLA. But, when I go and talk to more realistically human-sized companies who are doing cloud native or using containers and orchestrators and microservices, they don’t do it to be hyperscale. They do it because they can use it to push functionality out more quickly”.
So, what does cloud native mean to those companies? Anne’s take on cloud native comes down to three things:
• Build microservices: before anything else, move to microservices, as they’ll have the biggest impact
• Use existing services: don’t re-implement anything that is available as a cloud-based service
• Automate everything: automated testing, continuous integration, continuous delivery
“You can parallelize your teams more and so have more people at once working on features without them hitting one another. The difficulty is that distributed systems are really hard to do correctly”.
So are we over-thinking it?
Perhaps we should take the term “cloud native” more at face value: it simply means building for a cloud-like environment. That’s Nicki Watt’s take. She’s CTO of OpenCredo, a consultancy that helps companies adopt and adapt emerging technologies to solve business problems, which includes making use of cloud.
“I think it’s probably an overloaded term,” says Nicki, “For me, cloud native is really about making sure that the way you approach building your applications makes first class citizens out of being able to efficiently utilize your platform to scale, distribute and manage your systems in an automated way. At the moment, that’s predominantly cloud based”.
Ultimately, it comes back to Sam’s point that cloud native is about embracing the specifics of the platform.
“If you’re building systems to specifically take advantage of your platform’s cloud-like technologies and approaches, then these systems can be considered cloud native,” is Nicki’s view. “Take a simple example: Building a web application ten years ago would most probably involve a standard three tier architecture. Using a technology like Rails or Java EE paired with a trusty DBA managed database, the system would be built to operate within some relatively rigid hardware or infrastructure setup. Whilst scaling, monitoring, detecting and taking corrective actions on the components within the system may have had some consideration, they almost always required manual human intervention to achieve”.
For Nicki, cloud native is at least partly about freeing systems from needing human ops intervention.
“Building a cloud native web app equivalent today is about removing the need for rigid hardware and infrastructure. It’s about removing process that relies on manual intervention to keep things running. Instead, we’re building automation and distribution friendly applications that exploit our chosen cloud substrate’s capabilities. This includes being able to take advantage of on-demand services and heads towards applications with more reliable, self healing and auto scaling like characteristics”.
Logging is essential for Cloud Native
Cloud native as a definition is evolving rapidly, and there were a number of different approaches and viewpoints expressed at the conference. One element did come up often that’s required for cloud native environments: logging. Sam summarized the importance of logging in cloud native systems by stating:
“With distributed systems, the ephemerality of your processes comes to the fore and so you need to bring your logs together in one place to get a picture of what’s going on. The first thing I say if you are interested in implementing microservices is that you should implement aggregated logging straightaway”.
A key challenge we heard from attendees is that their cloud native systems consist of many moving parts which results in uncertainty. To remove this uncertainty, users want to go beyond monitoring and be able to aggregate log data easily and iteratively ask questions to gain context to fully understand what is happening in their system. We have designed Humio with this in mind, which our CTO, Kresten, goes into detail about in a previous blog post.
So “cloud native” might well be a loaded term, but it’s useful in bringing together all the thinking and assumptions behind systems that are built from the ground-up for cloud deployment. The Humio team could not be more excited about creating a log management tool that helps you build for any platform on any cloud. We look forward to continuing this ongoing discussion by sharing and learning from other developers that are surrendering themselves to a better and easier way of building cloud native applications.