Polyglot Cloud Native Compute Ain’t No Picnic!
Where I’m contemplating about cloud native compute and how we’re moving more and more into a polyglot setup.
So, what is this about? What do I mean by cloud native compute, why is it polyglot and what are the challenges we’re facing?
It’s really horses for courses, applied to cloud native compute. Pick the “right” compute form for a given workload; in real-world setups, many of those compute forms, such as containers or Function-as-a-Service (FaaS), will co-exist. It’s not a zero-sum game.
I’ve been wanting to write about the topic of polyglot cloud native compute (PCNC) for some time now. This week, at re:Invent, it feels the time is ripe and I’d like to share some thoughts about PCNC, essentially raising awareness and helping you to navigate the space a little better.
Why is the time ripe? Now that we’ve launched EKS on Fargate—a launch I’m grateful and proud to have contributed a bit—and witnessing talks at re:Invent such as Using containers & serverless to accelerate application development (linked below), I believe we’ve enough data points at hand to make a case.
But how to pick the “right” compute form?
Maybe, you’re currently running your application on a VM, bare metal, or on a mainframe. With the decision to modernize your app or to move it to the cloud, you’re faced with a number of choices? Can the (monolithic) app be moved as a whole or will you need to break it up in smaller functional units, potentially causing re-design and re-writes?
An exemplary comparison of containers and FaaS, based on a talk I yet have to give in public (hit me up if you want me to keynote it, LOL) looks as follows:
As you can see from above, both cloud native compute forms have some conceptually similar properties, such as how artifacts. However, there are also areas, such as lifting & shifting a monolith, where they clearly differ.
Potential criteria to choose the one over the other for a specific workload— while acknowledging the fact any non-trivial, real-world system will end up using a combination—could be as follows:
- Budget available, scope of the task, time-to-market required (you know, as in: pick two).
- Velocity desired, both developer-related and delivery/deployment-related.
- Organizational capabilities (such as up-training) and boundaries (can dev and ops talk to each other, directly, for example).
Wrapping up, I believe that we’re seeing PCNC becoming a reality and the more you know about pros and cons of different compute forms and their implications, the more informed your decisions become. Good luck, and remember: PCNC ain’t no picnic.
To circle back to the title: if you squint at the abbreviation for Polyglot Cloud Native Compute (PCNC) you might actually hear yourself saying “picnic”, so that’s what the pun was trying to convey. Sorry not sorry, Massimo, couldn’t resist ;)
