my 'simple vs complex' post touched some nerves. it shld have.- me a short while ago on the twitr machine
if you're starting w/ assumption 'we need containers', everything looks like an orch issue.
why do you need containers? first principles, folks
Why Do You Need Containers?
Let’s cut right to the point:
if you can’t clearly answer that question in one or two sentences, you don’t need containers.
You can stop reading now.
Still here? Ok, let’s think through why we would need containers.
This refers to something like processing an incoming event - a piece of text, an image or whatever - with a set of steps that are identical to every thing of this type.
For example, a speech recording is generated that is then sent into a transcription process. The incoming event will possess the same attributes - audio blob, date+time, user origin, etc - across hundreds of thousands of invocations. The processing that you want to run can be expressed as a single function.
It may be complex but it’s still a single function. You don’t care about anything other than the inputs & outputs to this process.
This is exactly how I designed Tincup Voice (now private). This is my arch diagram for the service, which conspicuously doesn’t include anything about servers.
I have a set of EC2 instances behind the target group that provides the front-door service in the form of a nodejs server providing account management, initiation of new transcripts & the UI/UX of the mini-site, which is a hugo blog-per-member.
What server is running this? You don’t care.
What size instance is powering this? You don’t care.
What type of load balancing & scaling is behind this? You don’t care.
You care about the version of the runtime that the function invokes, those inputs & outputs and in some cases, the time it takes to run.
Pay attention to that if any part of your process takes close to 30 secs. Thirty seconds (last time I checked) was the point at which API Gateway calls would timeout. If your post-processing requires using some other service, you may have to avoid API Gateway and implement your own. I did.
So, you do want containers here, but not directly. You want a serverless approach.
You only care about the function.
Running your thing - the function - in lambda or another serverless service makes sense.
You don’t care about any of the infrastructure that runs the thing. Why should you care?
Here’s where that old joke shines: Serverless is not actually serverless. They’re just someone else’s and as long that someone else is competent & keeps them running, you don’t care.
Beyond what I mentioned in https://jbminn.com/posts/the-case-for-containers/, that’s it.
If I have a complex environment, I’m going to deploy it all on instances. I get tight, on-metal (virtual) control of ports, addresses & names. I have no interest in managing a whole other scheme that simply replaces the functionality I already have.
You can - and should - smartly use both auto-scaling and load balancing to ensure that you aren’t overprovisioned. Even if you find that the instance type itself is too large or small, it can be adjusted.
Create a new image & point your target group at it or however it works in your provider of choice.
First principles.- jbminn
in this post, I mention service names specific to AWS. if you use another provider, the concepts should be pretty similar