The start-up culture has become quite a hot topic recently, bringing with it a wave of people exclaiming corporate is bad and start-ups are the single truth. While I do agree to a point, there are, as always, nuances. Having worked in both environments I happen to have some thoughts to share. Otherwise, you wouldn’t be here, would you?
First let’s discuss start-ups
The first and possibly the most obvious perk of working in a start-up, or even building your own endeavor is the complete and total freedom to choose. You get to choose everything.
The language you application is written in; its frameworks; its standards; its patterns; whether you want to use REST or RPC styles. Need a database? There are a dozen solid options.
Then there’s the runtime. Bare metal; virtualized servers; serverless; do you handle deployments yourself or do you want to have a platform do magic for you? Basically, choice of runtimes depends on how much you want to abstract away to some magic box.
Detour: abstractions
In 2023, I attended DevOpsCon in Berlin, Germany, and one of the talks was from Hugh McKee from Lightbend titled “Beyond Serverless: How Feature-Focused Platforms Streamline Your DX”. Although not the exact presentation from DevOpsCon, a quite similar looking one is available on YouTube. The talk is about using Kalix to deploy infrastructure alongside and from within your application code. Basically, you use Java annotations to describe the application’s need for a database, or a Kafka cluster, or Redis cache, and Kalix just handles it.
I personally despise most abstractions (more on that some other time).
That being said, I did come to the realization why Hugh was so fascinated by this tech long after the talk and the conference were over.
You see, Hugh has been a developer for many-many moons. Enough moons to have gone through the bootstrapping of a project too many times.
Endless choices
And I absolutely understand his position. A software project is never just about the software. You might think you only need a simple service; a simple tiny webapp, but very often the tiny webapp needs a database. Great, now you need to either deploy the database server (and configure it) or throw currency at a provider. Technically you could plonk a db container next to your application, but we don’t do that here.
You might want to know what your application is saying about itself through logs. Because you carefully crafted your logs to
be informative, contain only the necessary information while leaving out the bloat. Option 1: ssh into your server and
look at a file; option 2: set up a centralized log management stack using Graylog, Humio, Loki, or something else; or
option 3; throw currency at an aaS provider to have them set it up for you.
But also
Now you need to communicate with your application. Open ports? Yes. TLS? Uhh… You must choose. Either embed TLS stuffs in your webapp or use an external tool.
I personally stand by separation of concerns. Meaning the application does not need to know anything about TLS. It just needs to know how to listen to traffic and act on it. The TLS part should be handled by a reverse-proxy. And honestly, there are quite a few good ones - nginx, Caddy, and Traefik, to name some, but there are like a hundred more of them out there. Or you can throw currency at an aaS provider to have them set it up for you.
Okay good. Now how do you know if and how well the app is running? Metrics (or observability). Hoo boy. One option is to observe everything - CPU, memory, storage, request latency, request counts, status codes, geo-origins, traces, etc. The other option is to either occasionally ping your service and hope it responds. Or wait for annoyed users email/call you. You still need to set it up, though. The usual candidates are Prometheus and Grafana in the case of metrics, or some uptime monitoring tool like Uptime Kuma in the case of occasional pings. You need to implement the application side anyway, but do you deploy and configure the stack yourself, or throw currency at an aaS provider to have them set it up for you?
One last thought. I personally quite like automations. Some might say a little too much, even. This manifests in me really liking Continuous Deployments. I push code to my git provider, the automation compiles and packages it, and then deploys it to my server (or aaS provider).
Also bear in mind all of the above is mostly from the application side. I’ve not talked about deployment of infra. How to provision VMs? How to manage users? Central user repo or plonk an SSH public key into the VM? How to authorize your automations to work on your infra? How to deploy the application on said infra?
To wrap it all up, an application deployment is never just and application deployment. There’s a bunch of supporting stuff that needs to be in order before your app can function. Yes, some are not necessarily required, but are really frickin’ convenient to have, while others you simply cannot do without.
Working corporate
Working in corporations is bad! You never get to decide anything! You are always told what to do!
The upper management decides on the direction the organization is headed, what general, overarching goals should be set
and worked towards, what features to ruin by tacking AI to them. There will most definitely be pivots, re-prioritizing,
dropping old goals in favor of new goals, etc. And you as just one of the cogs frankly don’t have much say in it.
Yes, but.
You are (at least in my case) quite spoiled.
Remember the section about endless choices where you had to pick, choose, and match every single piece in your tech stack to work with one another?
Need a database? Just add your db name in this file and our automation will take care of it (while being already configured, mind you).
Need application compilations? Someone has set up the GitHub Actions ecosystem.
TLS is already automatically enforced through pre-configured reverse-proxies/ingresses (and possibly even in inter-cluster communication, if you’re into that sort of stuff).
Observability is achieved by inserting your application’s details into a file, from where already set up systems start scraping data your app emits.
What I’m saying is, many, if not all of those systems are already set up and working. Many of the practices are already established. You just have to learn and replicate (and improve, because you’re not a programmer, but a developer).
But what about the balances?
I quite like a thought by a colleague of mine that goes something like
Few things are objectively better than others. Every option, every choice has its benefits and shortcomings. Ones you must understand and take into account when making decisions.
A dance of trade-offs, if you will.
Do you want to work in an environment where many choices are chosen for you, walk the path many have walked before and many are yet to walk? Or do you want to make your own choices, but at the cost of paving the way?
Do you have spare currency to throw at providers or will you take on the duties of an entire department?
To be clear, there are no right or wrong answers here - every soul must choose their own fate.
Poetic, isn’t it?