Over the past year I’ve taken a step back and evaluated how we build and deploy web applications.
When we talk about modernising web applications people immediately jump to the cloud-native catch phrase.
It ramps up pretty quick, it spirels quickly into kubernetes, docker, Paas, Ingress, load balancing, service mesh and site reliability engineering. For most people there is very little meaning and value in these terms, just hype and complexity.
For me it comes down to a few things:
- minimising costs – utilising resources more effectively – better isolation
- authenticating and authorizing easier and in a more future-proof way
- making our web apps more reliable
- making our web apps easier to build and maintain
- making our web apps easier to deploy
- are our lives easier?
- are our outcomes achieved faster?
I am not so sure that the cloud native and microservices approach which is part-and-parcel to it has achieved any of the above points.
Minimising Costs, Efficient resource usage and Isolation
I like the ability to run multiple applications on a cluster or node and have the scheduling of this done for you.
I also like that all is isolated…you don’t need to deploy multiple applications on a single vm and then use virtualhost or server blocks.
That also adds to the reliability and deployment part.
Although learning about containers and kubernetes, also deploying your own cluster and managing that requires many hours of learning (like 500+ hours).
It also needs many hours of application. The subject matter also moves fasts and deprecates things so there is not a single way of doing something or a kata that you can follow.
Also at the end of the day your kubernetes cluster is on nodes, the nodes are most likely vms (unless hidden from you by your cloud provider).
So you are still on computers and the computers cost money…utilisation may also remain low based on your app usage.
Most applications never need to scale and can therefore avoid the complexity.
I would doubt that any website in South Africa gets more than 300M hits a day.
So a lot of the shit is overkill.
Authenticating and authorizing easier
This isn’t part of the cloud native foundation and there isn’t much clarity here.
There isn’t a clear winner but this is a very important thing to get right espescially when organisating a sweet of applications or microservices.
You should deletegate or outsource your authnetication and authorisation from your application.
It should be done at one single (HA) source.
Certainly LDAP is much better than authenticating with your specific frameworks authntication method – as their is a single source.
Even better than that is OAuth and when you add an identity to OAuth you get OpenID Connect. You delegate authentication in your applciation to something like Keycloak and let it handle all auth and authorization related stuff.
You are not a hero…let someone else do this hard and ubiquitous job for you.
Searching online it looks like istio and linkerd (the service mesh frontrunners) are trying to muscle in on auth for your services.
Making our web apps more reliable
From my experience so far, using k8s too deploy a project initially and scale it up and down hasn’t added to reliability.
It has taken away from it.
On one of my django projects the vm has been running for a very long time:
14:39:38 up 610 days, 4:58, 1 user, load average: 0.00, 0.01, 0.05
Availability has been always (100%) except for like a second during deploys.
Building your application in a lightweight and performance based way without excessive bloat and crap is still the number 1 thing you can do.
Making our web apps easier to build and maintain
I think apps have become harder to build and maintain.
When you build a python based django or flask site you can write a few lines going through their tutorial and be up and running with a website in no time at all.
When doing this with a container it is longer and you need to make tough choices, like the base image, environment variables, externalising the db from sqlite.
On top of that it is hard to debug. Your standard debugger like ipdb and debugbar are hard to configure to work in containers…also depending on the base image you cant just access the container and run commands.
You need to read the logs and then make changes.
A kak developer experience and the tooling is not up to stratch.
Also it is alot to learn (as I mentioned before) and apply. Just getting your application into an image is tough, you then need to deploy that image to a private registry.
Then you need to write the manifest or spec for k8s to access the registry and then create the deployment/replicaset or pods for the app.
It is messed up.
Perhaps in the long run it is easier but doesn’t feel like that now.
Making our web apps easier to deploy
It is a total mind shift to deploy containerised apps.
You need a registry and need to set environment variables – so that like the 12 factor app principles your test, staging and production images are very similar.
Easier said than done.
I still need alot to do here like look at jenkinsx or gitlab on how this is to be done (cause jenkins old has got a bad rep).
I will wait until I’ve taken a few more steps to commend on this.
Are our lives easier
Fuck no.
We aren’t google…but apparently we need to be google cause our small 10 hits a day website is now google level priority for site reliability and scale.
We’ve also had to learn so much stuff for so long and we aren’t closer to answering some basic questions.
are our outcomes achieved faster
Don’t know, don’t think so.