Introduction
In the beginning of the month I posted about my experience of moving VMchooser from “Serverless” to “Containers”. As in, moving from one way of implementing a CloudNative architecture to another… Since then, I have actually moved back to “Serverless”.Ā Though the cogwheels in my head have been turning 24/7 on how to put everything around this into perspective. Yesterday Yves made a tweet (reply) that really made something click inside of my head…
In today’s post I’m going to try to do a “brain dump” of several thoughts that have been floating around in my mind. Where I hope this will help you in your journey of “finding your perfect rock”. Here I will indicate what I like about the various options and what my typical advice would be to organizations looking to do a given option.
Why I like : Containers
About five years ago I started my first experiments with containers. By the end of 2015 I had moved the compute logic of my entire home setup over to being containerized. Why did I do this? First of all, because real life projects are the best way to learn things! š Next to that, it solved the “It works on my machine”-paradigm and provided me with a way to make components of my home setup portable & repeatable. Suddenly I was able to quickly setup a new environment. If it was from either a development perspective or due to (hardware) migration, it did not matter.
The funky thing was, that the entire orchestrator space at that time was still fully in flux. You can pretty much compare it to the current state of “Service Mesh”. Several parties were trying to gain the much needed adoption / mind share… Where at that time, you could already notice that Kubernetes was winning over the community. Though, maybe surprisingly, I was not a fan of Kubernetes myself. Docker Swarm was just a lot more intuitive, and easy to use, compared to Kubernetes. On the other hand, if you pushed Docker Swarm beyond a certain limit, it would come falling down in pieces. That was of course not a pretty sight… Though I did got won over by Rancher, and even made community contributions to the Azure Resource Manager Templates repository to make it work nicely with Azure. I can honestly say that Rancher taught me how to work with Docker! The user interface surfaced the docker elements I wasn’t aware of, and helped make Docker accessible.
Though for me, containers are a form of Configuration Management, where on its own you could achieve the same thing with tools like ; System Center, Chef, Puppet, Ansible, … Be aware that I am not saying you will achieve the same thing. Though looking at it from 10-mile high view, that is basically what it was doing for a lot of people. Luckily by now, the capabilities around it have matured and a container implementation will go beyond that.
Why I like : Kubernetes
With Kubernetes winning over the community, the biggest advantage was having a “standard” on which a new ecosystem could be born. With the “war” between Mesosphere, Docker Swarm/Enterprise & Kubernetes going on, it was a though one for any project to truly build on a stable surface. As I mentioned Rancher earlier on, they are a prime example of this. With Kubernetes winning, they actually pivoted from their original value proposition and aligned with this trend in the market. Basically reinventing a large chunk of themselves, compared to the initial space they were aiming for!
That being said… I see Kubernetes as the “cross platform”-platform of this era. What VMware realized with vSphere in the previous era, Kubernetes will do for this one. It serves as a platform on which you can build your platform in a fully portable manner… being cross-cloud ; public/private/hybrid. It will allow you to run the same payload virtually anywhere. That is a huge plus! If you are an ISV without a SaaS offering, this should be your “go to” implementation form. As you can have a uniform layer, that will be pretty much consistent across implementation platforms. This is by the way a similar pattern that you can notice with Azure Arc, which is also leveraging Kubernetes as the underlying platform to deliver “Azure Data Services Anywhere” for example.
Why I like : Serverless
When I started off with containers, my mind was going “WHY ISN’T EVERYONE USING THIS ALREADY?!?”… and then I started off with “Serverless”. Suddenly I was thinking “We should skip containers and go immediately to Serverless!”. Why was that? Containers and Kubernetes are still heavily “infrastructure oriented”. Let us be blunt and honest ; It solved the “It works on my machine”-paradigm, but it still resides on the infrastructure implementation level. Where it does not add any business value, aside from the architecture principle “Portability”. It gives you the ability to “easily” move workloads from one service provider to another. So for organizations that want to be totally agnostic of the service provider used, and want to put forward additional investments to achieve this, it would make a lot of sense.
Now we come at the point why I like Serverless… I see the implementation of my projects as a phase in time. For instance, both the VMchooser backend and frontend are currently in their 3th generation. That is about one generation per year… With every generation, I pick the best options available at that time. For me, that moment in time is the point where you could pivot to another service provider. In my architecture, I think in terms of endpoints and how I can evolve those during the application / workload / solution lifecycle. Combine that with the fact that I can align my designs with the cost dimensions of my service provider, that means that I can heavily cost optimize my solution.
In my move from Serverless to Containers, I had to make a heavy investment in terms of knowledge (about three months of learning) and to foresee capabilities that were foreseen before (by the Serverless services; like CORS, SSL, Authentication, …). This whilst being hit with a higher operational cost! On one hand I saw my running cost of about 150 Euro per month go to about 800 Euro for the same capabilities. And on the other hand I needed to do more operational work to keep the lights on. Here you could argue that I am a lousy architect… š Though I am not the only one who has tweaked his/her architecture to be fully cloud optimized. Check out Troy Hunt’s post from about 1,5 year ago on “Have you been pwned”.
To link back to the previous section about Kubernetes, if you are an ISV with a SaaS offering… This should be your “go to” platform, unless if you want to invest in a “multi cloud” strategy. Which from a business continuity point-of-view might make sense, though be aware this might come at a cost penalty on TCO level.
My two cents when running ; Containers (and by extension Kubernetes)
It is fair to say, that we can all agree… running Kubernetes is hard. This is basically why most organizations run these workloads in the Cloud. In my current role, I talk to a lot of organizations about containers and I do see some who are able to pull off a self managed container platform (either On Premises or by leveraging IaaS components). Though, truth be told, they are more the exception than the rule and they need a very skilled & sizeable team to achieve this. Next to that, there is another set of customers who have been trying to set up a container platform for about 3 to 4 years. Where they then have to admit that this investment has not given them the results they would have hoped for. Where the majority of organizations has “more than enough other problems to worry about”… and they simply do not want to invest in running their own container platform.
“I got 99 problems, but Kubernetes should not be one”
The typical advice I give to customers (exceptions are always there, though as a rule of thumb) ;
- Leverage a Managed Certified Kubernetes service if you are looking to run containers
=> Thus do not try to run your own platform, either on premises or in the cloud. Leverage a managed one. - Do not put any state (persistent storage, databases, …) into the platform (at first) and look towards managed offerings.
- You might not need an orchestrator (like Kubernetes), as things like Azure App Service, Azure Container Instance, etc might suffice.
My two cents when running ; Serverless
Think in terms of “endpoints”. What do I mean with this? In terms of your application lifecycle, think of the interfaces you need between services of the ones consuming your service. For instance ; Microsoft SQL or MongoDB are common interfaces that you can implement anywhere. Azure will provide a managed service for both, which will already relief you of a lot of operational worries. Want to move to On Premises or another cloud provider? No problem, you can run those there too. The other kind of endpoints are the way you are serving components both internally and externally. It might be worthwhile to create a simple abstraction layer between for example your code and the messaging service it is using.
Looping back to the twitter quote in the introduction… By leveraging (for example) Terraform / Pulumi for your desired state, you can already take over a lot of the things you would want to do with Helm/Dockerfiles. So leverage automation tooling as much as possible. My personal preference is to use ;
- Terraform in terms of landscaping (though I know others do love Pulumi for this tool)
- Also populating Azure KeyVault etc
- Azure DevOps Pipelines in terms of automation/orchestration.
- Azure KeyVault to store / share my secrets for internal services
- GitHub to store all the code for both my application workloads as the infrastructure-as-code repositories
And of course, the advice on the container side also applies here… Managed Services help like a lot! If you go for the Serverless route, always think in terms of “First Party Services” (Managed services delivered directly supplied by the provider). Try to stay clear of “hybrid” (meaning between PaaS and IaaS for example) setups, as it will typically overcomplicate a lot of things and reduce your agility by a lot. I know… General rule of thumb here, as your mileage may vary due to X. Though try to see it as an exception.
Closing Thoughts
I hope the above “mind dump” helps you on your journey into the CloudNative space! The IT sector has never been an easy one to understand and follow. It is always in flux and complex at best… š
Though be aware of the side effects of the pill you are choosing… There is no silver bullet, there never is! Like a Dutch football (soccer) trainer once said ; Every advantage has its disadvantage. My personal sentiment is that the gist is choosing between portability and fine grained cost optimization.
Karim Vaes 