I have worked with database code that was meant to only work with the database it was running on, and database code that was meant to be agnostic to what database you used. I always thought that the costs of the second were underappreciated relative to their benefits. And unless you're actively maintaining running on more than one database (as in, shipping a product where your users have more than one database) you tend to miss all the implicit ways you come to depend on the implementation you're on -- yes, the syntax may be the same across databases, but performance impacts are different, and so you tend to optimize based on the performance of the database you're on.
I suspect the same is true for cloud. Real portability has real costs, and if you aren't incurring all of them up front and validating that you're doing the right things to make it work, then incurring part of them up front is probably just a form of premature optimization. At the end of the day, all else being equal, it's easier to port a smaller codebase to new dependencies than a larger one, and attempting to be platform-agnostic tends to result in more code as you have to write a lot of code that your platform would otherwise provide you.
It’s not just portability that’s an issue with lambda. It’s also churn.
Running on Lambda, one day you’ll get an email saying that we’re deprecating node version x.x so be sure to upgrade your app by June 27th when we pull the plug. Now you have to pull the team back together and make a bunch of changes to an old, working, app just to meet some 3rd party’s arbitrary timeframe.
If you’re running node x.x on your own backend, you can choose to simply keep doing so for as long as you want, regardless of what version the cool kids are using these days.
That’s the issue I find myself up against more often when relying on Other People’s Infrastructure.
It's not about using what the cool kids use these days.
I can't stress enough that unmaintained software should not run in production.
This way you have a good argument towards management and if you do it regularly or even plan it in ahead of time it's usually not much work.
During a product planning meeting:
"Dear manager, for the next weeks/sprint the team needs X days to upgrade the software to version x.x.x otherwise it will stop working"
Isn't that always the case though? I mean, outside of e.g. lambdas or other platforms / runtimes as a service?
I mean a few years ago there was a huge security flaw in Apache Struts, whose impact was big because it had been used in a lot of older applications - meaning a LOT of people had to be summoned to work on old codebases to fix this issue.
The problem isn't a changing runtime - even if you self-host it you should make sure to keep that updated regularly.
Since late last year, you can use old versions if you want to. [0] The provider doesn't enforce the runtime anymore. But I don't think it's the provider issue in the first place. At some point "node x.x" will be EOL and you won't get an email. You'll just stop getting maintenance patches.
Good point, but no. If you have architected your apps properly, decommissioning or sunsetting services or individual components should already have been designed and planned.
They didn’t pull the plug. You can’t create or update new lambdas with older versions of Node, but if you have existing code, it won’t just stop working.
> If you’re running node x.x on your own backend, you can choose to simply keep doing so for as long as you want, regardless of what version the cool kids are using these days.
What do you mean by your own backend? Your own physical hardware, your own rented hardware, your own EC2 box, your own Fargate container?
What if you get an office fire, a hardware failure, a network outage, a required security update, your third party company goes out of business, etc.?
There's no such thing as code that doesn't need to be maintained. Lambdas (and competitors) probably require the least maintenance of the lot.
The unifying lesson I've been appreciating after reaching my 30s is that in order to make good decisions, an individual needs to have a very clear understanding of how something works. If you know how something works, then you can foresee problems. You can explain the correct use cases for a particular tool. You know the downsides just as well as the upsides for a particular choice.
In software development, a lot of the new stuff that is supposed to solve our problems just shifts those problems somewhere else -- at best. At worst, it hides the problems or amplifies them. This isn't unique to software development, but it seems to be particularly pervasive because so much is invisible at the onset of use.
Best advice, be very suspicious when someone can't explain what the bad parts are.
There are also a terrible cost of running just on one database, the dependency on just one provider.
In business you should never depend on just one provider. This provider could be the best in the world, now, because it has amazing management. But people die, or are hit by a bus, or get crazy after a divorce or just retire and they get replaced by the antitheses.
In my personal experience, real portability has great benefits on their own. Design is easier to understand and you constantly find bugs thanks to running your software in different architectures, compilers and so on.
At the end of the day, it is the quality of your team. If your team is bad, your software will be bad and vice versa.
Funny thing is, the fact alone that you create a provider-agnostic system can give you enough performance or cost penalties that you want to change providers in the first place.
You can't use provider specific optimizations, so the provider seems bad and you don't wanna use it.
The big difference with something like PL/SQL is that it’s a proprietary language, whereas lambda and the other faas options are based on open languages. Makes portability somewhat easier to achieve.
For sure; the external interface of a lambda is trivial, that is, a single entrypoint function with an 'event'. It's relatively easy to create a simple wrapper around that to make it either provider agnostic or self-hosted.
Good points, but it remains to be seen whether the portability of large serverless apps is sufficient to prevent the providers from squeezing their customers once they are deeply established.
The fact that there’s three major cloud providers (who will at the very least compete on customer acquisition) is a point in favor of this, but it’s definitely an experiment. In my mind, this is as much about negotiating power as it is about technical tradeoffs.
Well, there is a cost to be portable and the cost to adapt an app that's not portable.
Whether it's DB independence or cloud provider independence, from my experience it's cheaper to pay the cost of the migration when you know you want to migrate (even if it involves rewriting some parts) rather than paying it everyday by writing portable code.
Most of the time the portable code you write becomes obsolete before you want to port it.
You're only thinking about the _input_. Technically, yes, I can host an express app on lambda just like I could by other means, but the problem is that it can't really _do_ anything. Unless you're performing a larger job or something you probably need to read/write data from somewhere and connecting to a normal database is too slow for most use-cases.
Connecting to AWS managed services (s3, kinesis, dynamodb, sns) don't have this overhead so you can actually perform some task that involves reading/writing data.
Lambda is basically just glue code to connect AWS services together. It's not a general purpose platform. Think "IFTTT for AWS"
We have been connecting to mongo db from without lambda for the past year and sure you don't get single digit latency but r/w data happens under 30ms in most cases, we even use paramastore to pull all secrets and it's still without that time frame.
But that is the whole point of using cloud services that are tightly integrated with each other. I can not do it as efficiently as Amazon myself can not be called "propriety lock-in".
OK. So you connect to Postgres on RDS - cloud agnostic.
You connect to S3, and:
a) You can build an abstraction service if you care about vendor lock-in so much
b) It has an API that plenty of open source projects are compatible with (I believe Google's storage is compatible as well)
Maybe you use something like SQS or SNS. Bummer, those are gonna "lock you in". But I've personally migrated between queueing solutions before and it shouldn't be a big deal to do so.
It's really easy to avoid lockin, lambda really doesn't make it any harder than EC2 at all.
Our Lambda deployments handle REST API Gateway calls, SQS events, and Step functions. Basically the entire middleware of a classic 3-tier stack.
Except for some proprietary light AWS proxy code, the bulk of the Lambdas delegate to pre-existing Java POJO classes.
The cold start issues and VPC configuration were a painful learning curve, but nothing I would consider proprietary to AWS. Those are universal deployment tasks.
> Unless you're performing a larger job or something you probably need to read/write data from somewhere and connecting to a normal database is too slow for most use-cases.
This is false. I've seen entire Lambda APIs backed by MySQL on large, consumer-facing apps and websites. As another poster pointed out, the cold-start-in-a-VPC is a major PITA, but it can (mostly) be worked around.
I think it probably isn't purely the use of lambda/serverless but the creep of other things that make it more difficult to leave. Stuff like cognito or SNS or other services. Once you start using AWS, each individual choice in isolation looks cheaper and easier to just use something AWS provides. Once you start utilizing 7+ different AWS services it becomes very expensive to transition to another platform.
Also, this conversation is very different if you are an early stage company racing to market as opposed to an established organization where P&L often takes precedence over R&D.
At my previous place I saw this in reverse. Over the previous years we had invested in building up our own email infrastructure.
Because so much had been invested (sunk cost fallacy), no-one could really get their heads around a shift to SES, even though it would have been a slam dunk in improved reliability and developer productivity.
Whereas if we were on, say, Mailgun, and then someone wanted a shift to SES, that debate could probably have been a more rational one.
I just point this out to say that investing in your own infrastructure can be a very real form of lock-in itself.
This is the same model of buying things on amazon too -- once you've bought once, it's easier to buy again. Why spend time going to another shop when you can just use amazon to buy multiple things.
This ease of use philospohy goes way back to the one-click patent. If I want DNS, why wouldn't I go to amazon, which has all my finance details, and a decent interface (and even API), rather than choosing another DNS provider, setting up my credit card, and having to maintain an account with them. So I choose DNS via AWS. Then I want a VPS, but why go to linode and have the overhead of another account when I could do lightsail instead?
Seeing that as long as Y combinator has existed, only one company has ever gone public, the rest are still either humming along unprofitably, have been acquired, or gone out of business, the chances of most businesses having to worry about their largest business risk being an over reliance on AWS seems slim.
In most cases, very few companies have products that need to scale to extreme load day 1 or even year 1. IMO, instead of reaching for the latest shiny cloud product, try building initially with traditional databases, load balancing, and caching first. You can actually go very far on unsexy old stuff. Overall, this approach will make migration easier in the cloud and you can always evolve parts of your stack based on your actual needs later. Justify switching out to proprietary products like lambdas, etc once your system actually requires it and then weigh your options carefully. Everyone jumping on the bandwagon these days needs to realize: a LOT of huge systems are still rocking PHP and MySQL and chasing new cloud products is a never ending process.
In my case switching to an AWS API Gateway + Lambda stack means I have zero-downtime, canary deployments that take less than 5 minutes to deploy from version control. Api Gateway is configured using the same swagger doc that autogenerates my request/response models (go-swagger) and (almost) completely removes routing, request logging, throttling and authentication concerns from the request handlers. Combined with a staticly hosted front-end and SNS/SQS+lambda pub-sub for out-of-process workers I never have to worry about auto-scaling, load-balancing or cache-invalidation and we only pay for what we use. It may not suit every use case, but in our case, we have bursty, relatively low-volume traffic and the hosting bill for our public-facing site/service that comprises most of the main business revenue is the same as a rounding error on our BI service bill.
This (pay for what you use, so many fewer scalability issues) is so big it, by itself, can give you a competitive advantage against anyone who isn't doing this, which is almost everyone.
Maybe I'm overstating it, but I don't think I am...
With Google Firebase Functions I was able to start writing REST APIs in minutes.
Compare that to setting up a VM somewhere, getting a domain name + certs + express setup + deployment scripts, and then handling login credentials for all of the above.
I had never done any of that (eventually I grew until I had to), so serverless let me get up and running really quickly.
Now I prefer my own express instance, since deployment is much faster and debugging is much easier. But even for the debugging scenario, expecting everyone who wants to Just Write Code to get the horrid mess of JS stuff up and running in order to debug, ugh.
(If it wasn't for HTTPS, Firebase's function emulator would be fine for debugging, as it is, a few nice solutions exist anyway.)
But, to be clear, on day 1 the option for me to write a JS rest endpoint was:
1. Follow a 5-10 minute tutorials on setting up Firebase Functions.
OR
1. Pick a VM host (Digital Ocean rocks) and setup an account
2. Learn how to provision a VM
3. Get a domain
4. Get domain over to my host
5. SSH into machine as root, setup non-root accounts with needed permissions
6. Setup certbot
7. Learn how to setup an Express server
8. Setup an nginx reverse proxy to get HTTPS working on my Express server
9. Write deployment scripts (ok SCP) to copy my working code over to my machine
10. Setup PM2 to watch for script changes
11. Start writing code!
(12. Keep track, in a secure fashion, of all the credentials I just created for the above steps!)
I am experienced in a lot of things, and thankfully I had some experience messing around with VMs and setting up my own servers before, but despite what everyone on HN may think, not every dev in the world also wants to run a bunch of VMs and manage their setup/configuration just to write a few REST endpoints!
So yeah, instead I can type 'firebase deploy' in a folder that has some JS functions exported in an index.js file and a minute later out pops some HTTPS URLs.
If you don't want to learn DevOps why not use a PaaS like Heroku? That way when you want to learn DevOps, you can move your application without rewriting large swathes of it.
It's funny but when I learned to code basically all ISPs provided you with free hosting and a database, and you just needed to drag and drop a PHP file to make it live. It's like we have gone backwards not just in terms of openness but also in terms of complexity.
This seems a bit exaggerated. You definitely don't need to start with certbot or even with a domain name. Why can't you just start with a regular server on localhost, which can be set up in way less than ten minutes, and publish it only when you're ready? Not to mention that Firebase Functions is way less beginner-friendly than Express.
I'm generally a proponent of DIY, this doesn't make sense. When an org needs to scale, it makes sense to cultivate skill in the underlying infrastructure. On day 1, serverless makes a lot of sense because it encourages development patterns that eventually will scale nicely.
I have mixed feelings about this and I don't have enough experience to label on method better than the other.
Lambdas basically require zero maintenance. SQS requires zero maintenance. EC2 load balancer is zero maintenance. And the setup is trivial too and there's no migration time down the line.If you start off with native cloud for everything you can keep your maintenance and setup costs down drastically.
However, a lot can be done with the old school unsexy tech.
Zero maintenance? What about standing up multiple environments for staging, prod? Sharing secrets ,keys, and env vars? Deployments? Logging? No migration time down the line? I'm pretty sure GCP, Azure don't have Lambda, SQS, or EC2 load balancers so you absolutely will have migration time if you have to retool your implementation to switch cloud providers or products.
Honestly, I've developed the last few projects in Serverless framework and deployed to AWS Lambda. My biggest project is a custom Python application monitoring solution that has 4 separate Lambda function/handlers, populates an RDS PostgresSQL database with monitoring data (runs in a VPC), then reads from that database using complex joins across multiple application metric tables to send time-series data to Cloudwatch metrics.
Then, I configured Cloudwatch alarms to have thresholds for certain metrics that send a web hook to PagerDuty.
The benefit is that my monitoring system never goes down, never needs to be patched manually (AWS even patches my Postgres database, and fails over to the warm standby during patching), and never needs any system administration.
Have you ever worked at a company where you had a serious outage that you didn't detect quickly enough because a monitoring system was down? Having a Serverless monitoring system means this has happened 0 times despite our app running in production for almost a year now.
> In most cases, very few companies have products that need to scale to extreme load day 1 or even year 1.
That wouldn't be a great reason to choose serverless indeed. However, that doesn't mean serverless isn't still the right choice.
We've tried both the traditional approach you describe and serverless, and from experience the latter is 10x less infrastructure code than the former (we compared both Terraform implementations).
If serverless fits your use case, saving time and effort is a very good reason to go for it IMHO.
Of all the AWS features to criticism for lock-in, Lambda seems like the weakest choice.
You don't have to write much code to implement a lambda handler's boilerplate, and that boilerplate is at the uppermost or outermost layer of your code. You could turn most libraries or applications into lambda functions by writing one class or one method.
A lambda's zip distribution is not proprietary and is easy to implement in any build tool.
I'd include the triggers as part of that analysis, like being able to invoke a function every time something is pushed to an S3 bucket for example. Just being able to run arbitrary functions without caring about the OS is the core product, but the true value is that you can tie that into innumerable other services that are so helpfully provided.
Basically, AWS has so much damn stuff under their belt now, and it all integrates so nicely, every time they add a new feature it lifts up all the other features as a matter of course.
I tend to agree, although with most things I think it depends on how heavily invested you are. Migrating a handful of mission-critical Lambdas is no biggie, but if you've really bought the bait and implemented your entire web services architecture on AWS API Gateway and Lambda -- for some reason -- you've got a much tougher job untangling yourself. Perhaps it suffices to say it's worth keeping an eye on how much friction you're building for yourself as you go.
"I'm scared of vendor lock-in, so I'm going to build something that's completely provider agnostic" means you're buying optionality, and paying for it with feature velocity.
There are business reasons to go multi-cloud for a few workloads, but understand that you're going to lose time to market as a result. My best practice advice is to pick a vendor (I don't care which one) and go all-in.
And you'll forgive my skepticism around "go multi-cloud!" coming from a vendor who'll have precious little to sell me if I don't.
That sounds like the perspective of someone who's picked open source vendors most of the time, or has been spoiled by the ease of migrating Java, Node, or Go projects to other systems and architectures. Having worked at large enterprises and banks who went all in with, say, IBM, I have seen just how expensive true vendor lock-in can get.
Don't expect a vendor to always stay competitively priced, especially once they realize a) their old model is failing, and b) everybody on their old model is quite stuck.
I am incredulous that people wouldn't be worried about vendor lock-in when the valley already has a 900lb gorilla in the room (Oracle).
Ask anybody about Oracle features, they'll tell you for days about how their feature velocity and set is great. But then ask them how much their company has been absolutely rinsed over time and how the costs increase annually.
Oracle succeed by being only slightly cheaper than migrating your entire codebase. To offset this practice, keep your transition costs low.
--
Personal note: I'm currently experiencing this with microsoft; all cloud providers have an exorbitant premium when it comes to running Windows on their VMs, but obviously Azure is priced very well (in an attempt to entice you to their platform). Our software has been built over a long period of time by people who have been forced to run Windows at work -- so they built it on Windows.
Now we have a 30% operational overhead charged from microsoft through our cloud provider. But hey.. at least our cloud provider honours fsync().
At least if you went with IBM and followed the old adage “no one ever got fired for buying IBM” in the 80s, you can still buy new supported hardware to run your old code on. If you went with their competitors, not so much.
> That sounds like the perspective of someone who's picked open source vendors most of the time
More than that. They picked open source vendors that didn't (a) vanish in a puff of smoke, (b) get bought out by a company that slowly killed the open source version, or (c) who produced products that they were capable of supporting without the vendor (or capable of faking support for).
Vendor lock in can be expensive, but spreading yourself across vendors can also be expensive. There are lots of events that are free if you stay in the walled garden, but the second you starting pulling gigs & gigs of data from AWS S3 into GCP (or whatever), that can get pricey real fast.
In general I agree with you. In practice, the more practical approach may be to focus on making more money & not fussing too much w/ vendor costs & whatever strategy you choose to use. It's easy to pay a big vendor bill when there's a bigger pile of cash from sales.
My best-practice advice is to do the math. What is the margin on infrastructure vs. the acquisition and management costs of the engineers necessary to operate the infrastructure.
Serverless doesn't scale very well in the axis of cost. At some point that's going to become an issue. If one has gone "all-in" on vendor lock-in then that vendor is going to spend as much time as possible enjoying those margins while the attempts to re-tool to something else is underway.
Best practice, generally speaking is to engineer for extensibility at some point, fairly early on.
Self hosting doesn't scale. There is very little reason for a good sysadmin to work for International Widgets Conglomerated when they can work for a cloud provider instead, building larger scale solutions more efficiently for higher pay. I'd rather buy an off the shelf service used by the rest of the F500 than roll my own. Successful companies outsource their non core competencies
It doesn't have to be that way, for a client I've recently set up a Gitlab Auto Devops on Google Kubernetes. Feature velocity wise it is nearly as painless as Heroku (which to me is the pinnacle of ease of deployment), but because every layer of the stack is open source we could switch providers at a flick of the wrist.
Of course, we won't switch providers, because they're offering great value right now.
I feel this vendor lock-in business is a phase that will pass. We were vendor locked when we paid for Unix or Windows servers, then we got Linux and BSD. Then we got vendor locked by platform providers like AWS and such, and now that grip is loosened by open source infrastructure stacks like Kubernetes.
> We were vendor locked when we paid for Unix or Windows servers, then we got Linux and BSD.
NT was released in -93, FreeBSD 2.0 (free of AT&T code) was released in -94. GNU/Linux also saw professional server use in mid/late 90's. People still lock themselves in though.
If a company is going from zero to something, then you are absolutely right. In that case, dealing with vendor lock in later means success!
If an established company is moving to the cloud, the equation is not as simple. The established company presumably has the money and time to make their vendor agnostic. Is the vendor lock in risk worthwhile to spend more now? How large is the risk? What are the benefits (using all of the AWS services is pretty nice)?
>"benefits (using all of the AWS services is pretty nice)"
your personal experience? Or are you simply assuming that interop / efficiencies obtain when going all-in on AWS? I ask, because I've had multiple client conversations in which these presumed benefits fail to materialize to a degree that offsets the concern about lock-in.
If your time horizon is short (months to a couple of years) going all-in with a vendor can work quite well. Over longer time horizons (several years or more), it's often not so great. Forgetting about the costs involved (i.e. they know they've got you) and the fact that if that one vendor ever becomes truly dominant that improvements will slow to a crawl (i.e. they know they've got everyone), there is a very real risk of whatever technologies you are depending on disappearing as their business needs will always outweigh yours. Feature velocity tends to evaporate in the face of a forced overhaul or even rewrite.
Pricing changes are a real issue. Google maps spiked in cost and those who were using leaflet JS just had to change a few settings to switch to another provider. Those who built using googles map js are locked in.
The problem with that is, there's only one thing, some product manager somewhere, that sits on a light switch of your company or project's success or failure. They could even unintentionally end you with a price change.
For instance, putting your EC2 instances in a VPC has been the preferred way of operating since 2009. But, if you have an account old enough, you can still create an EC2 instance outside of a VPC.
You can still use the same SQS API from 2006 as far as I know.
At first this seems reasonable from a 'technical debt' perspective. Building in vendor-agnosticism takes extra resources (true), that you could spend on getting features to market (true), you can always spend those extra resources later if you succeed and need them... sort of true, not really. Because the longer you go, the _more expensive_ it gets to switch, _and_ the more disruptive to your ongoing operations, eventually it's barely feasible.
Still, I don't know what the solution is. Increasingly it seems to me that building high-quality software is literally not feasible, we can't afford it, all we can afford is crap.
There's a middle ground here. You can decide on a case by case basis how much lock-in you are willing to tolerate for a particular aspect of your system. You can also strategically design your system to minimize lock-in while still leveraging provider specific capabilities or "punting" on versatility when you want to.
In other words you can decide to not bother with worrying about lock-in when it costs too much.
This will make your code base easier to port to multi-cloud in the future if you should ever want to.
Obviously, there's a huge cost associated with the learning curve, but this the part of the reason that Kubernetes is so attractive. It abstracts away the underlying infrastructure, which is nice.
At any kind of scale, though, one is loosely coupled to the cloud provider in any case for things like persistent disk, identity management, etc.
This, and if you really really don't want vendor lock-in, instead of inventing your own infra APIs, find the API the cloud vendor you chose exposes, replicate it, make sure it works, and then still use the vendor with the comfort of knowing you can spin your own infra if the cloud provider no longer meets your needs.
Or you don't bother replicating the API, even if you don't want vendor lock-in, because you realize that if a cloud provider evaporates, there will be a lot of other people in the same boat as you and surely there will be open-source + off-the-shelf solutions that pop-up immediately.
Agree that time to market shouldn't be impeded by any unnecessary engineering.
But pick a vendor and go all-in can work for netflix'y big companies or ones with static assets on cloud. All cloud providers have their own rough edges and if you get stuck in one you might be losing your business edge. Case in point - not going to name the provider since we are partners with them, we found a provision bug - custom windows image based vm took 15 minutes to get provisioned and also exporting custom image across regions has rigid size restrictions. The provider acknowledged the bugs but they are not going to address it in this quarter but if we are netflix big - may be they could have addressed it sooner.
We have automated the cluster deployment so we can get our clusters up and running in most major cloud providers. We are careful not to be tied to vendor lock-in as much as possible since business edge cannot be compromised based on this big cloud providers, who only heed to your cry only if you are big and they care none what so ever for your business impediment. When you are expecting cloud resources which aren't going to be static - you need flexibility so the above recommendation doesn't suit all.
I'll echo this sentiment, and while it may sound like a philosophical position it really is pragmatic experience: it is nearly impossible to realize a gain from proactively implementing a multi-vendor abstraction. I've found this to hold in databases, third party services like payments and email, and very much so in cloud services. I instead recommend using services and APIs as they were designed and as directly (i.e. with as little abstraction) as possible. Only when and if you decide to add or switch to another vendor would be the time to either add an abstraction layer or port your code. I've never seen a case where the cost to implement two direct integrations was significantly more than the the cost to implement an abstraction, and many cases where an abstraction was implemented but only one vendor was ever used.
I'll note that I have no objection to abstractions per se, especially in cases where a community solution exists, e.g. Python's sqlalchemy is good enough that I'd seldom recommend directly using a database driver, Node's nodemailer is in many cases easier to use than lower level clients, etc.
It very much depends on the nature of the services and the abstractions.
I'm currently working on a system that has several multi-vendor abstractions - for file storage across AWS, GCP, NFS and various other things; for message queues across Kafka, GCP Pubsub, and direct database storage; for basic database storage (more key-value style than anything else) across a range of systems; for deployment on VMs, in containers, and bare metal; and various other things.
All of these things are necessary because it's a complex system that needs to be deployable in different clouds as well as on-prem for big enterprise customers with an on-prem requirement.
None of the code involved is particularly complex, and it's involved almost zero maintenance over time.
That would less be the case if you were trying to roll your own, say, JDBC or DB-agnostic ORM equivalent, but there are generally off the shelf solutions for that kind of thing.
I agree with this, but would note that building an abstraction layer is not the only way to approach this issue. Just building the thing with half an eye on how you would port it over to a different platform is you needed to can make the difference between it being a straightforward like-for-like conversion, and having to rearchitect the entire app...
I've been at places where they were so vendor locked to a technology that there was a penalty clause for leaving that was in the tens of millions. It obviously wasn't cloud but the point still stands. If you don't have options you pay what they tell you or go out of business.
Yeah, I can't help but wonder about offerings like AppSync; in one level it seems cool, but I recoil a the thought of introducing a critical dependency on AWS for a core piece of the application layer.
This has been my company's approach.
There's always going to be some provider specific stuff you have to deal with.. The networking has been a major difference between clouds I've noticed. But I'm guessing in most cases our Helm charts would deploy unchanged Toa different provider.
At the expense of losing what little reputation I have on HN I will say this:
As many others on here seem to be correctly saying, i think this article amounts to fear mongering of vendor lock in. The modern public cloud is very different from the Oracle/IBM mainframes of yester-year.
The whole point of the public cloud is to leverage managed services to their fullest extent so you can move incredibly fast. As a startup, you’ll run laps around your competitors doing all of this from scratch simply to preserve their non vendor lock in.
The notion that removing that glue code that glues your code to AWS or Azure managed services amounts to vendor lock in, that is no more true than any other code running on any VM that talks to those same managed services. Except the main difference here is that your not wasting time writing the glue code.
Additionally Azure Functions or AWS Lambda, or even Functions on Kubernetes, which are meant to be the smallest unit of work when used correctly (similar to a MicroService) and should contain only your application logic are “vendor lock-in” is absolutely rediculous to me. If anything when you do decide to move vendors this will be the easiest code in the world to migrate, inputs and outputs.
I will concede that it is hard to see this the way I’m describing if you haven’t actually worked on the modern public cloud and are not actively taking advantage of managed services on there for speed of delivery.
A little self promotion: as an example of what’s actually possible with these Serverless frameworks I recently built a cross platform app, as a side project in just a few months nights and weekends with the entire backend as Serverless Functions, the app can read any article to you, using some open source ML models for text to speech, and can be found https://articulu.com if you want to check it out.
There is a certain amount of arrogance to always being afraid of vendor lock-in. Most companies don’t survive, even the best ones might be just around for 20-25 years. The big worry should be on building a business that won’t immediately die.
And even with Oracle (probably the primo example of lock-in) it’s not like there aren’t firms who’s sole speciality is pumping data out of the Oracle DB and transforming it magically into T-SQL. It’s never the end of the world with vendor lock-in.
NOTE: now vendor lock-out does scare me like no other ironically
> It’s never the end of the world with vendor lock-in.
I think that's a matter of scale. Using Oracle for your counter example isn't very persuasive, as that's a huge vendor, so there's a market to extract you. Not so for many other vendors.
> Most companies don’t survive
...and ensuring they can control their costs and pivot away from solutions that prove too complex is part of being able to survive.
I mean, I agree, vendor lock-in doesn't have to be the end, but it also makes sense to extricate yourself when you can. When I worked for Virginia state govt they made a deal with Northrup Grumman...one that the legislative audit group came by later and said it was such a terrible deal that we should drop it...except we couldn't afford the exit costs, so we had to stick with a deal that was bad in terms of both money and quality.
That's a position you don't want to be in, and that result "It's bad but we can't afford to get out of it" is what the fear of vendor lock in is all about.
The only YCombinator company to go public - Dropbox - started life completely dependent on AWS, proved product market fit, got funding and slowly moved from AWS.
Other companies like Netflix decided that they didn’t want to manage infrastructure and proudly announced they closed down their final data center and moved to AWS.
Twitter desperately needs to move everything as quickly from self hosting as possible.
Not the person you're responding to, but I worry about (and have experienced) both with my tech stack, even as I've purposefully switched vendors multiple times with minimal headaches.
Locking yourself into a single vendor is easier to voluntarily work your way out of than your vendor shutting down or shutting you out unexpectedly. But the good news is if you plan for one you get the other for free.
I would argue that small to medium web services don’t need Kubernetes nor serverless. It doesn’t even need to be split into services. Build a tidy monolith and see how far that takes you first. Have less moving parts.
Yes, serveless ties you in to platform specifics but in their nature the functions you create should be small and easy to reimplement elsewhere.
Kubernetes on the other hand is arguably also a certain lock-in, by virtue of being complicated. No wonder vendors love it, it’s an offering that is hard to do right in-house. And when Kubernetes releases updates only the most seasoned in-house teams will be able to keep up. It creates job security by being a lot to learn and manage. Yes there are good abstractions but when something breaks you’ll need to delve into that complexity below. (Makes me think of ORM abstractions vs SQL.)
Yes, Kubernetes is an awesome vehicle for orchestrating a swarm of containerized services. But when you’re not Netflix or Twitter scale it’s ridiculous to worship this complexity.
Frankly I keep coming back to appreciate Heroku's abstractions and its twelve factor app philosophy https://12factor.net/. Heroku runs on AWS but feels like a different world than AWS to develop on. I can actually get projects flying with a 2-3 person team me included.
Actually 'serverless' is where small shops might want to start.
A single Lambda can encompass a whole variety of functions, and if you're using a datastore that scales as well, you don't need to worry about much. Once it's set up, it should be very easy to monitor and change.
I'd rather a simple Lambda than managing a couple of EC2's with failover scenarios and the front end networking pieces for that.
Also small scale is where lambda really shines in terms of costs. If you have some api endpoint that gets a hit 100 times per hour and does some execution then this is actually way cheaper then even the cheapest ec2 instance in a production setup with ELB.
There's a world of organizations between Netflix and Twitter scale and small startups with 2-3 person infrastructure teams in which Kubernetes makes good sense.
At some point, it becomes cost effective to have a two-pizza team of engineers dedicated to it. Once an org hits that level, then the scale that can be achieved with Kubernetes is pretty immense.
I'm using k8s for a side project on Digital Ocean. I'm familiar with k8s, and deployment and maintenance are easy. The only devops I've gotten into so far is setting up DNS for the external load balancer. I think people are mistaken when they say k8s is too complex for the smallest apps.
Readit News
I suspect the same is true for cloud. Real portability has real costs, and if you aren't incurring all of them up front and validating that you're doing the right things to make it work, then incurring part of them up front is probably just a form of premature optimization. At the end of the day, all else being equal, it's easier to port a smaller codebase to new dependencies than a larger one, and attempting to be platform-agnostic tends to result in more code as you have to write a lot of code that your platform would otherwise provide you.
Running on Lambda, one day you’ll get an email saying that we’re deprecating node version x.x so be sure to upgrade your app by June 27th when we pull the plug. Now you have to pull the team back together and make a bunch of changes to an old, working, app just to meet some 3rd party’s arbitrary timeframe.
If you’re running node x.x on your own backend, you can choose to simply keep doing so for as long as you want, regardless of what version the cool kids are using these days.
That’s the issue I find myself up against more often when relying on Other People’s Infrastructure.
This way you have a good argument towards management and if you do it regularly or even plan it in ahead of time it's usually not much work.
During a product planning meeting: "Dear manager, for the next weeks/sprint the team needs X days to upgrade the software to version x.x.x otherwise it will stop working"
I mean a few years ago there was a huge security flaw in Apache Struts, whose impact was big because it had been used in a lot of older applications - meaning a LOT of people had to be summoned to work on old codebases to fix this issue.
The problem isn't a changing runtime - even if you self-host it you should make sure to keep that updated regularly.
[0] https://aws.amazon.com/blogs/aws/new-for-aws-lambda-use-any-...
I know, I know... It's almost never the case.
What do you mean by your own backend? Your own physical hardware, your own rented hardware, your own EC2 box, your own Fargate container?
What if you get an office fire, a hardware failure, a network outage, a required security update, your third party company goes out of business, etc.?
There's no such thing as code that doesn't need to be maintained. Lambdas (and competitors) probably require the least maintenance of the lot.
Until you get audited, and that raises a flag, and now you have to deal with it.
Using an old version of Node is just going to leave you with worse performance and potentially security holes.
In software development, a lot of the new stuff that is supposed to solve our problems just shifts those problems somewhere else -- at best. At worst, it hides the problems or amplifies them. This isn't unique to software development, but it seems to be particularly pervasive because so much is invisible at the onset of use.
Best advice, be very suspicious when someone can't explain what the bad parts are.
In business you should never depend on just one provider. This provider could be the best in the world, now, because it has amazing management. But people die, or are hit by a bus, or get crazy after a divorce or just retire and they get replaced by the antitheses.
In my personal experience, real portability has great benefits on their own. Design is easier to understand and you constantly find bugs thanks to running your software in different architectures, compilers and so on.
At the end of the day, it is the quality of your team. If your team is bad, your software will be bad and vice versa.
Funny thing is, the fact alone that you create a provider-agnostic system can give you enough performance or cost penalties that you want to change providers in the first place.
You can't use provider specific optimizations, so the provider seems bad and you don't wanna use it.
The fact that there’s three major cloud providers (who will at the very least compete on customer acquisition) is a point in favor of this, but it’s definitely an experiment. In my mind, this is as much about negotiating power as it is about technical tradeoffs.
Whether it's DB independence or cloud provider independence, from my experience it's cheaper to pay the cost of the migration when you know you want to migrate (even if it involves rewriting some parts) rather than paying it everyday by writing portable code.
Most of the time the portable code you write becomes obsolete before you want to port it.
For example:
Using this template.
https://github.com/awslabs/aws-serverless-express
I’ve been able to deploy the same code as a regular Node/Express app and a lambda with no code changes just by changing my CI/CD Pipeline slightly.
You can do the same with any supported language.
With all of the AWS services we depend on, our APIs are the easiest to transition.
And despite the dreams of techies more than likely after awhile, you aren’t going to change your underlying infrastructure.
You are always locked into your infrastructure choices.
Connecting to AWS managed services (s3, kinesis, dynamodb, sns) don't have this overhead so you can actually perform some task that involves reading/writing data.
Lambda is basically just glue code to connect AWS services together. It's not a general purpose platform. Think "IFTTT for AWS"
It’s a standard CRUD REST API used by our website.
The only thing slow is infamous cold start time when running within a VPC because it has to create an ENI.
AWS pinky promised they were going to fix this soon.
You connect to S3, and:
a) You can build an abstraction service if you care about vendor lock-in so much
b) It has an API that plenty of open source projects are compatible with (I believe Google's storage is compatible as well)
Maybe you use something like SQS or SNS. Bummer, those are gonna "lock you in". But I've personally migrated between queueing solutions before and it shouldn't be a big deal to do so.
It's really easy to avoid lockin, lambda really doesn't make it any harder than EC2 at all.
Except for some proprietary light AWS proxy code, the bulk of the Lambdas delegate to pre-existing Java POJO classes.
The cold start issues and VPC configuration were a painful learning curve, but nothing I would consider proprietary to AWS. Those are universal deployment tasks.
This is false. I've seen entire Lambda APIs backed by MySQL on large, consumer-facing apps and websites. As another poster pointed out, the cold-start-in-a-VPC is a major PITA, but it can (mostly) be worked around.
Also, this conversation is very different if you are an early stage company racing to market as opposed to an established organization where P&L often takes precedence over R&D.
Because so much had been invested (sunk cost fallacy), no-one could really get their heads around a shift to SES, even though it would have been a slam dunk in improved reliability and developer productivity.
Whereas if we were on, say, Mailgun, and then someone wanted a shift to SES, that debate could probably have been a more rational one.
I just point this out to say that investing in your own infrastructure can be a very real form of lock-in itself.
This ease of use philospohy goes way back to the one-click patent. If I want DNS, why wouldn't I go to amazon, which has all my finance details, and a decent interface (and even API), rather than choosing another DNS provider, setting up my credit card, and having to maintain an account with them. So I choose DNS via AWS. Then I want a VPS, but why go to linode and have the overhead of another account when I could do lightsail instead?
If you use provider agnostic solutions, things get expensive quick.
Stuff like SNS and Cognito is much cheaper in terms of TCO.
If you don't use them you can switch providers more easily, but if you use them you wouldn't need to switch providers.
On top of that. I lose the “easy button” of depending on our AWS business support contract if something gets wonky.
sorry -
isn't the _entire context_ of this article (and your response, experience, etc) 'implications of changing an underlying infrastructure' ?
yes, this isn't something one does on a whim, but it does happen, as your own post suggests.
Yeah, nowadays it's done by dissolving the company or being bought out, then shut down.
Still, it's the same thing. Use of inadequate infrastructure being, let's say, terminated.
What do you consider the lock in when using RDS? S3? EC2?
The cool kids don’t do large apps, we do microservices. (Said ironically I’m in my mid 40s - far from a kid.)
Dead Comment
Maybe I'm overstating it, but I don't think I am...
With Google Firebase Functions I was able to start writing REST APIs in minutes.
Compare that to setting up a VM somewhere, getting a domain name + certs + express setup + deployment scripts, and then handling login credentials for all of the above.
I had never done any of that (eventually I grew until I had to), so serverless let me get up and running really quickly.
Now I prefer my own express instance, since deployment is much faster and debugging is much easier. But even for the debugging scenario, expecting everyone who wants to Just Write Code to get the horrid mess of JS stuff up and running in order to debug, ugh.
(If it wasn't for HTTPS, Firebase's function emulator would be fine for debugging, as it is, a few nice solutions exist anyway.)
But, to be clear, on day 1 the option for me to write a JS rest endpoint was:
1. Follow a 5-10 minute tutorials on setting up Firebase Functions.
OR
1. Pick a VM host (Digital Ocean rocks) and setup an account
2. Learn how to provision a VM
3. Get a domain
4. Get domain over to my host
5. SSH into machine as root, setup non-root accounts with needed permissions
6. Setup certbot
7. Learn how to setup an Express server
8. Setup an nginx reverse proxy to get HTTPS working on my Express server
9. Write deployment scripts (ok SCP) to copy my working code over to my machine
10. Setup PM2 to watch for script changes
11. Start writing code!
(12. Keep track, in a secure fashion, of all the credentials I just created for the above steps!)
I am experienced in a lot of things, and thankfully I had some experience messing around with VMs and setting up my own servers before, but despite what everyone on HN may think, not every dev in the world also wants to run a bunch of VMs and manage their setup/configuration just to write a few REST endpoints!
So yeah, instead I can type 'firebase deploy' in a folder that has some JS functions exported in an index.js file and a minute later out pops some HTTPS URLs.
It's funny but when I learned to code basically all ISPs provided you with free hosting and a database, and you just needed to drag and drop a PHP file to make it live. It's like we have gone backwards not just in terms of openness but also in terms of complexity.
Lambdas basically require zero maintenance. SQS requires zero maintenance. EC2 load balancer is zero maintenance. And the setup is trivial too and there's no migration time down the line.If you start off with native cloud for everything you can keep your maintenance and setup costs down drastically.
However, a lot can be done with the old school unsexy tech.
So I'm mixed.
Then, I configured Cloudwatch alarms to have thresholds for certain metrics that send a web hook to PagerDuty.
The benefit is that my monitoring system never goes down, never needs to be patched manually (AWS even patches my Postgres database, and fails over to the warm standby during patching), and never needs any system administration.
Have you ever worked at a company where you had a serious outage that you didn't detect quickly enough because a monitoring system was down? Having a Serverless monitoring system means this has happened 0 times despite our app running in production for almost a year now.
That wouldn't be a great reason to choose serverless indeed. However, that doesn't mean serverless isn't still the right choice.
We've tried both the traditional approach you describe and serverless, and from experience the latter is 10x less infrastructure code than the former (we compared both Terraform implementations).
If serverless fits your use case, saving time and effort is a very good reason to go for it IMHO.
You don't have to write much code to implement a lambda handler's boilerplate, and that boilerplate is at the uppermost or outermost layer of your code. You could turn most libraries or applications into lambda functions by writing one class or one method.
A lambda's zip distribution is not proprietary and is easy to implement in any build tool.
Basically, AWS has so much damn stuff under their belt now, and it all integrates so nicely, every time they add a new feature it lifts up all the other features as a matter of course.
Vendor lock-in is a thing, but Lambda are lower on the rungs than other things.
It's the hyper-specific things that imply heavier lock-in, especially those that bleed into other systems.
There are business reasons to go multi-cloud for a few workloads, but understand that you're going to lose time to market as a result. My best practice advice is to pick a vendor (I don't care which one) and go all-in.
And you'll forgive my skepticism around "go multi-cloud!" coming from a vendor who'll have precious little to sell me if I don't.
Don't expect a vendor to always stay competitively priced, especially once they realize a) their old model is failing, and b) everybody on their old model is quite stuck.
Ask anybody about Oracle features, they'll tell you for days about how their feature velocity and set is great. But then ask them how much their company has been absolutely rinsed over time and how the costs increase annually.
Oracle succeed by being only slightly cheaper than migrating your entire codebase. To offset this practice, keep your transition costs low.
--
Personal note: I'm currently experiencing this with microsoft; all cloud providers have an exorbitant premium when it comes to running Windows on their VMs, but obviously Azure is priced very well (in an attempt to entice you to their platform). Our software has been built over a long period of time by people who have been forced to run Windows at work -- so they built it on Windows.
Now we have a 30% operational overhead charged from microsoft through our cloud provider. But hey.. at least our cloud provider honours fsync().
More than that. They picked open source vendors that didn't (a) vanish in a puff of smoke, (b) get bought out by a company that slowly killed the open source version, or (c) who produced products that they were capable of supporting without the vendor (or capable of faking support for).
In general I agree with you. In practice, the more practical approach may be to focus on making more money & not fussing too much w/ vendor costs & whatever strategy you choose to use. It's easy to pay a big vendor bill when there's a bigger pile of cash from sales.
My best-practice advice is to do the math. What is the margin on infrastructure vs. the acquisition and management costs of the engineers necessary to operate the infrastructure.
Serverless doesn't scale very well in the axis of cost. At some point that's going to become an issue. If one has gone "all-in" on vendor lock-in then that vendor is going to spend as much time as possible enjoying those margins while the attempts to re-tool to something else is underway.
Best practice, generally speaking is to engineer for extensibility at some point, fairly early on.
Of course, we won't switch providers, because they're offering great value right now.
I feel this vendor lock-in business is a phase that will pass. We were vendor locked when we paid for Unix or Windows servers, then we got Linux and BSD. Then we got vendor locked by platform providers like AWS and such, and now that grip is loosened by open source infrastructure stacks like Kubernetes.
NT was released in -93, FreeBSD 2.0 (free of AT&T code) was released in -94. GNU/Linux also saw professional server use in mid/late 90's. People still lock themselves in though.
If an established company is moving to the cloud, the equation is not as simple. The established company presumably has the money and time to make their vendor agnostic. Is the vendor lock in risk worthwhile to spend more now? How large is the risk? What are the benefits (using all of the AWS services is pretty nice)?
>"benefits (using all of the AWS services is pretty nice)"
your personal experience? Or are you simply assuming that interop / efficiencies obtain when going all-in on AWS? I ask, because I've had multiple client conversations in which these presumed benefits fail to materialize to a degree that offsets the concern about lock-in.
For instance, putting your EC2 instances in a VPC has been the preferred way of operating since 2009. But, if you have an account old enough, you can still create an EC2 instance outside of a VPC.
You can still use the same SQS API from 2006 as far as I know.
Still, I don't know what the solution is. Increasingly it seems to me that building high-quality software is literally not feasible, we can't afford it, all we can afford is crap.
In other words you can decide to not bother with worrying about lock-in when it costs too much.
This will make your code base easier to port to multi-cloud in the future if you should ever want to.
At any kind of scale, though, one is loosely coupled to the cloud provider in any case for things like persistent disk, identity management, etc.
And then watch the CTO throw you out of his office.....
Or you don't bother replicating the API, even if you don't want vendor lock-in, because you realize that if a cloud provider evaporates, there will be a lot of other people in the same boat as you and surely there will be open-source + off-the-shelf solutions that pop-up immediately.
But pick a vendor and go all-in can work for netflix'y big companies or ones with static assets on cloud. All cloud providers have their own rough edges and if you get stuck in one you might be losing your business edge. Case in point - not going to name the provider since we are partners with them, we found a provision bug - custom windows image based vm took 15 minutes to get provisioned and also exporting custom image across regions has rigid size restrictions. The provider acknowledged the bugs but they are not going to address it in this quarter but if we are netflix big - may be they could have addressed it sooner.
We have automated the cluster deployment so we can get our clusters up and running in most major cloud providers. We are careful not to be tied to vendor lock-in as much as possible since business edge cannot be compromised based on this big cloud providers, who only heed to your cry only if you are big and they care none what so ever for your business impediment. When you are expecting cloud resources which aren't going to be static - you need flexibility so the above recommendation doesn't suit all.
I'll note that I have no objection to abstractions per se, especially in cases where a community solution exists, e.g. Python's sqlalchemy is good enough that I'd seldom recommend directly using a database driver, Node's nodemailer is in many cases easier to use than lower level clients, etc.
I'm currently working on a system that has several multi-vendor abstractions - for file storage across AWS, GCP, NFS and various other things; for message queues across Kafka, GCP Pubsub, and direct database storage; for basic database storage (more key-value style than anything else) across a range of systems; for deployment on VMs, in containers, and bare metal; and various other things.
All of these things are necessary because it's a complex system that needs to be deployable in different clouds as well as on-prem for big enterprise customers with an on-prem requirement.
None of the code involved is particularly complex, and it's involved almost zero maintenance over time.
That would less be the case if you were trying to roll your own, say, JDBC or DB-agnostic ORM equivalent, but there are generally off the shelf solutions for that kind of thing.
Deleted Comment
Perhaps standardizing on something like Terraform allows you to reduce the risk of going all-in on one vendor.
Similarly with Kubernetes; if you go all in on k8S, do you care where it's hosted or can you maneuver quick enough to the best provider?
There is however a large number of painfully learned lessons of vendor locked in systems... no one got fired for buying IBM, right?
Deleted Comment
As many others on here seem to be correctly saying, i think this article amounts to fear mongering of vendor lock in. The modern public cloud is very different from the Oracle/IBM mainframes of yester-year.
The whole point of the public cloud is to leverage managed services to their fullest extent so you can move incredibly fast. As a startup, you’ll run laps around your competitors doing all of this from scratch simply to preserve their non vendor lock in.
The notion that removing that glue code that glues your code to AWS or Azure managed services amounts to vendor lock in, that is no more true than any other code running on any VM that talks to those same managed services. Except the main difference here is that your not wasting time writing the glue code.
Additionally Azure Functions or AWS Lambda, or even Functions on Kubernetes, which are meant to be the smallest unit of work when used correctly (similar to a MicroService) and should contain only your application logic are “vendor lock-in” is absolutely rediculous to me. If anything when you do decide to move vendors this will be the easiest code in the world to migrate, inputs and outputs.
I will concede that it is hard to see this the way I’m describing if you haven’t actually worked on the modern public cloud and are not actively taking advantage of managed services on there for speed of delivery.
A little self promotion: as an example of what’s actually possible with these Serverless frameworks I recently built a cross platform app, as a side project in just a few months nights and weekends with the entire backend as Serverless Functions, the app can read any article to you, using some open source ML models for text to speech, and can be found https://articulu.com if you want to check it out.
And even with Oracle (probably the primo example of lock-in) it’s not like there aren’t firms who’s sole speciality is pumping data out of the Oracle DB and transforming it magically into T-SQL. It’s never the end of the world with vendor lock-in.
NOTE: now vendor lock-out does scare me like no other ironically
I think that's a matter of scale. Using Oracle for your counter example isn't very persuasive, as that's a huge vendor, so there's a market to extract you. Not so for many other vendors.
> Most companies don’t survive
...and ensuring they can control their costs and pivot away from solutions that prove too complex is part of being able to survive.
I mean, I agree, vendor lock-in doesn't have to be the end, but it also makes sense to extricate yourself when you can. When I worked for Virginia state govt they made a deal with Northrup Grumman...one that the legislative audit group came by later and said it was such a terrible deal that we should drop it...except we couldn't afford the exit costs, so we had to stick with a deal that was bad in terms of both money and quality.
That's a position you don't want to be in, and that result "It's bad but we can't afford to get out of it" is what the fear of vendor lock in is all about.
Other companies like Netflix decided that they didn’t want to manage infrastructure and proudly announced they closed down their final data center and moved to AWS.
Twitter desperately needs to move everything as quickly from self hosting as possible.
Locking yourself into a single vendor is easier to voluntarily work your way out of than your vendor shutting down or shutting you out unexpectedly. But the good news is if you plan for one you get the other for free.
Yes, serveless ties you in to platform specifics but in their nature the functions you create should be small and easy to reimplement elsewhere.
Kubernetes on the other hand is arguably also a certain lock-in, by virtue of being complicated. No wonder vendors love it, it’s an offering that is hard to do right in-house. And when Kubernetes releases updates only the most seasoned in-house teams will be able to keep up. It creates job security by being a lot to learn and manage. Yes there are good abstractions but when something breaks you’ll need to delve into that complexity below. (Makes me think of ORM abstractions vs SQL.)
Yes, Kubernetes is an awesome vehicle for orchestrating a swarm of containerized services. But when you’re not Netflix or Twitter scale it’s ridiculous to worship this complexity.
Frankly I keep coming back to appreciate Heroku's abstractions and its twelve factor app philosophy https://12factor.net/. Heroku runs on AWS but feels like a different world than AWS to develop on. I can actually get projects flying with a 2-3 person team me included.
Actually 'serverless' is where small shops might want to start.
A single Lambda can encompass a whole variety of functions, and if you're using a datastore that scales as well, you don't need to worry about much. Once it's set up, it should be very easy to monitor and change.
I'd rather a simple Lambda than managing a couple of EC2's with failover scenarios and the front end networking pieces for that.
At some point, it becomes cost effective to have a two-pizza team of engineers dedicated to it. Once an org hits that level, then the scale that can be achieved with Kubernetes is pretty immense.