Creating software designed to use the resources of the cloud should be the next major move for organizations who have migrated.
Join the DZone community and get the full member experience.Join For Free
What’s in a (Buzz)word?
I often have a love-hate relationship with buzzwords. On the one hand, they are usually so grossly abused and promiscuously thrown around as to almost lose all practical meaning. And yet, paradoxically, they often seem to be the only way to succinctly convey some concept.
Cloud-native is exactly such a buzzword. Lately, everything and anything seems to be labeled cloud-native. Don’t believe me? Google the phrases “cloud-native hardware,” “cloud-native sales specialist,” and "cloud-native accounting firm.” It’s an epidemic.
And yet…how else should we talk about the new wave of software that is being built with the express target of running on a public cloud platform? There doesn’t seem to be a better label. While I do have some affinity for the recently popularized “modern cloud applications,” I don’t really think that’s a step forward, and I am seriously considering buying the domain “modern cloud laundry detergent” before the gold rush begins.
As a security startup that has taken a very different approach to protecting these new kinds of applications, how can I start explaining what we do, if I can’t even talk meaningfully about what has changed?
So let's try and agree on what we mean by cloud-native. There are many definitions out there, and most are both way too detailed and yet surprisingly unhelpful. To me, the most useful way to understand the term cloud-native is that cloud-native is when we treat the cloud platform as an operating system. That’s really the whole philosophy behind it.
Historically, we have used the cloud as a way to consume virtualized hardware, such as compute, storage, and networking. When you “go cloud-native,” you move a level up and you design, build, deploy, and operate software that relies on the cloud platform to provide a rich set of services you can leverage and a useful abstraction that makes it easier to consume those services.
Like any other OS, you expect it to shield you from worrying about things like managing storage resources, matching processing needs to hardware cores, and handling complex tasks that are common across many applications. Like any other OS, you mostly don’t want to need to know the details of what goes on under the hood. Like any other OS, you sometimes do.
It’s the Principle of the Thing…
Let’s take a look at some of the key tenets of cloud-native software that flow from the above definition.
Used Managed Services Whenever You Can
If AWS is like Windows, then think of Kinesis as, let’s say, DirectX. If you’re looking to build a game for Windows, you’re probably not going to roll your own graphics rendering engine. You’re going to use what the native platform provides for you. If you’re looking to collect and process real-time streaming data, you shouldn’t be standing up some complex pipeline on EC2 machines. You should try and leverage Kinesis.
Let the Cloud Provider Handle Health and Scaling
Avoid architectures that require you to monitor health and load and deal with scaling. These are complex problems that involve both performance and cost, and they are the bane of most organizations’ existence. Modern cloud platforms increasingly provide an escape from these problems. Services like AWS Lambda and Google Cloud Run let you run code without handling scaling and health. Storage services like Azure Blobs or AWS S3 let you forget about capacity and throughput. This makes your application much more resilient, and also makes your operations much much simpler.
Code is for Business Logic
Writing code should be a last resort, and should mostly be reserved for implementing your valuable business logic. Everything else you need should be an API call away. If it’s not core to what you do, then someone else has already built it. Use them. They may look more expensive, but you need to factor in how much it costs you, not only to write code, but to test, maintain and operate it.
Stop Worrying About Vendor Lock-in
This is important. When you write software, there is nothing wrong with thinking about what happens if you need to switch platforms. But if you’re crippling your application so as to avoid using anything that might not exist in some future platform, then you are fighting with at least one hand behind your back. With public clouds, this is even more pronounced. You’re never locked into a single platform. You can always move some or all of your application to another cloud. So just focus on getting the most you can out of the platform you’ve chosen, and don’t stress too much about what happens when you decide to move.
And Also DevOps, CI/CD, Agile, and Twelve-Factor, Right?
This is the other thing people do. They lump everything they love together. There are many wonderful (and some not-so-wonderful) trends in building software. If you’re not automating everything you can (including security) into a modern CI/CD pipeline, then you’re going to suffer later. While these things are not directly related, it doesn’t mean you shouldn’t be following them. It just means you should be following them even if you’re building non-cloud-native software.
I guess, if I can’t beat them, I will join them. If you’re building cloud-native software, use cloud-native processes and a cloud-native architecture, and don’t forget some cloud-native security, cloud-native orchestration, and cloud-native operations while you’re at it...You get the idea.
For more information on Hillel and his work at Protego Labs, visit: https://www.protego.io/
Opinions expressed by DZone contributors are their own.