The many lies about reducing complexity part 2: Cloud

https://ea.rna.nl/2021/01/10/the-many-lies-about-reducing-complexity-part-2-cloud/

by rapnie • 6 years ago

224 125 6 years ago

ea.rna.nl

Reducing complexity should never be about platform (on-prem vs cloud).

It should be about constructing software in partnership with the business and reducing complexity with modeled boundaries.

You can leverage the cloud to do some interesting things, but the true benefit in is _what_ you construct, not _how_.

sanp• 6 years ago

There is an element of _how_ as well. You could create simple monoliths or overengineered microservices. Or, complex monoliths with heavy coupling vs cleanly designed microservices with clear separations of concern.

the-smug-one• 6 years ago

Are microservices meant to separate data too? As in, each service has its own database.

Wouldn't that lead to non-normalisation of the data or a lot of expensive network lookups to get what I want/need?

What is the point of micro services anyway :-)?

mumblemumble4• 6 years ago

I honestly believe that hiding complexity behind a closed door does not eliminate it. However, a lot of software and service vendors have a vested interest in convincing people otherwise. And, historically, they've had all sorts of great platforms for doing so. Who doesn't enjoy a free day out of the office, with lunch provided?

It's also much easier to hide complexity than it is to remove it. One can be accomplished with (relative) turnkey solutions, generally without ever having to leave the comfort of your computer. Whereas the other generally requires long hours standing in front of a chalkboard and scratching your head.

SpicyLemonZest• 6 years ago

On the other hand, hiding complexity behind closed doors can be a very valuable thing, if it lets you keep track of who knows about the complexity behind each. I can't count the number of issues I've encountered that would have taken minutes instead of hours if only I'd known which specific experts I needed to talk to.

hinkley2• 6 years ago

It's also much easier to hide complexity than it is to remove it.

There are multiple ways to hide complexity. Some of them make it easier to remove (eg, refactoring), others make it nearly impossible to remove. In a service market there’s a perverse incentive to move toward the latter.

bob1029• 6 years ago

This shared responsibility principle that underlies cloud marketing speak sounds a lot like the self-driving mess we find ourselves in today - I.e. the responsibility boundary between parties exists in a fog of war and results in more exceptions than if one or the other were totally responsible.

We have been a customer of Amazon AWS for ~6 years now, and we still really only use ~3 of their products: EC2, Route53 and S3. I.e. the actual compute/memory/storage/network capacity, and the mapping of the outside world to it. Because we are a software company, we write most of our own software. There is no value to our customers in us stringing together a pile of someone else's products, especially in a way that we cannot guarantee will be sustainable for >5 years. We cannot afford to constantly rework completed product installations.

We strongly feel that any deeper buy-in with 3rd party technology vendors would compromise our agility and put us at their total mercy. Where we are currently positioned in the lock-in game, we could pull the ripcord and be sitting in a private datacenter within a week. All we need to do is move VMs, domain registrations and DNS nameservers if we want to kill the AWS bill.

I feel for those who are up to their eyeballs in cloud infrastructure. Perhaps you made your own bed, but you shouldn't have to suffer in it. These are very complex decisions. We didn't get it right at first either. Maybe consider pleading with your executive management for mercy now. Perhaps you get a shot at a complete redo before it all comes crashing down. We certainly did. It's amazing what can happen if you have the guts to own up to bad choices and start an honest conversation.

I would also be interested to hear the other side of the coin. Who out there is using 20+ AWS/Azure/GCP products to back a single business app and is having a fantastic time of it?

rvanmil• 6 years ago

We carefully select and use PaaS and managed cloud services to construct our infrastructure with. This allows us to maximize our focus on what our customers are paying for: creating software for them which will typically be in use for 5+ years. We spend close to zero time on infrastructure maintenance and management, we pay others to do this for us, cheaper and more reliable. Having to swap out one service for another hasn't given us any trouble or unreasonable costs yet in the past 5 years. Unlike the article is trying to convince us of, it has massively reduced complexity for us.

bane2• 6 years ago

I've worked with a number of teams over the last few years who use AWS and I'd say from top to bottom they all build their strategy more or less the same way:

0. Whatever is the minimum needed to get a VPC stood up.

1. EC2 as 90%+ of whatever they're doing

2. S3 for storing lots of stuff and/or crossing VPC boundaries for data ingress/egress (like seriously, S3 seems to be used more as an alternative to SFTP than for anything else). This makes up usually the rest of the thinking.

3. Maybe one other technology that's usually from the set of {Lambda, Batch, Redshift, SQS} but rarely any combination of two or more of those.

And that's it. I know there are teams that go all in. But for the dozen or teams I've personally interacted with this is it. The rest of the stack is usually something stuffed into an EC2 instance instead of using an AWS version and it comes down to one thing: the difficulties in estimating pricing for those pieces. EC2 instances are drop-dead simple to price estimate forward 6 months, 12 months or longer.

Amazon is probably leaving billions on the table every year because nobody can figure out how to price things so their department can make their yearly budget requests. The one time somebody tries to use some managed service that goes overbudget by 3000%, and the after action figures out that it would have been within the budget by using <open source technology> in EC2, they just do that instead -- even though it increases the staff cost and maintenance complexity.

In fact just this past week a team was looking at using SageMaker in an effort to go all "cloud native", took one look at the pricing sheet and noped right back to Jupyter and scikit_learn in a few EC2 instances.

An entire different group I'm working with is evaluating cloud management tools and most of them just simplify provisioning EC2 instances and tracking instance costs. They really don't do much for tracking costs from almost any of the other services.

harikb• 6 years ago

I bet cloud providers are incentivized not to provide detailed billing/usage stats. I remember having to use a 3rd party service to analyze our S3 usage.

Infinite scalability is also a curse - we had a case where pruning history from an S3 bucket was failing for months and we didn’t know until the storage bill became significant enough to notice. I guess in some ways it is better than being woken up in the middle of night but we wasted millions storing useless data

Azure also has similar issues - deleting a VM sometimes doesn’t cleanup dependent resources and it is a mess to find and delete later - only because the dependent resources are deliberately not named with a matching tag.

hyperdimension2• 6 years ago

I'm not very familiar with AWS or The Cloud, but I'm having trouble understanding what you said about Amazon leaving money on the table by not directing customers toward specific-purpose services as opposed to EC2?

Wouldn't (for AWS to make a profit anyway) whatever managed service have to be cheaper than some equivalent service running on an EC2 VM?

I get the concerns re: pricing and predictability, but it still seems like more $$$ for AWS.

bird_monster7• 6 years ago

+1, but with a container tool (Fargate/ECS, Azure Container Instances) instead of EC2.

maria_weber23• 6 years ago

I second that. It's not only that you make yourself completely intertwined with a Cloud by using more than fundamental services.

The costs of lambda or even DDB are IMMENSE. These only pay off for services that have a high return per request. I.e. if you get a lot of value out of lambda calls, sure, use them. But for anything high-frequency that earns you little to nothing on its own, forget about it.

Generally all your critical infrastructure should be Cloud independent. That narrows your choices largely to EC2, SQS, perhaps Kinesis, Rout53, and the like. And even there you should implement all your features with two clouds, i.e. Azure and AWS, just to be sure.

The good news is also the bad news. There are effectively only two options: Azure or AWS. Google Cloud is a joke. They arbitrary change their prices, terminate existing products, offer zero support. It's just like we have come to love Google. They just don't give a shit about customers. Google only cares about "architecture", i.e. how cool do I feel as engineer having built that service. Customer service is something that Google doesn't seem to understand. So think carefully if you want to buy into their "product". Google, literally, only develops products for their own benefit.

jbmsf5• 6 years ago

I can't agree, at least not in general.

The optionality of being cloud agnostic comes with a huge cost, both because of all the pieces you have to build+operate and because of the functionality you have to exclude from your systems.

I am sure there are scales where you either have such a large engineering budget that you can ignore these costs or where decreasing your cloud spend is the only way to scale your business. But for the average company, I can't see how spending so much on infrastructure (and future optionality) pays off, especially when you could spend on product or marketing or anything else that has a more direct impact on your success.

singron• 6 years ago

Do you have examples of Google Cloud arbitrarily changing prices and terminating products?

Sure they terminate consumer products, and there was a Maps price hike, but I'm not aware of anything that's part of Cloud.

0xEFF• 6 years ago

Google Cloud has quite good support and professional services.

I’ve worked with them for 3 years and can’t think of any services that have been killed.

They are very customer focused. From my perspective as a partner cloud services are more built for customer use cases than Google internal use cases. GKE and Anthos for example.

jbmsf5• 6 years ago

It's always a trade-off though. You say you write most of your own software, but that's probably not true for, say your OS or programming language, or editors, or a million other things. Cloud software is the same; you might not be producing the most value if you spend your engineering hours (re)creating something you could buy.

In my own experience:

- AWS SNS and SQS are rock solid and provide excellent foundations for distributed systems. I know I would struggle to create the same level of reliability if I wrote my own publish-subscribe primitives and I've played enough with some of the open source alternatives to know they require operational costs that I don't want to pay.

- I use EC2 some of the time (e.g. when I need GPUs), but I prefer to use containers because they offer a superior solution for reproducible installation. I tend to use ECS because I don't want to take on the complexity of K8S and it offers me enough to have reliable, load-balanced services. ECS with Fargate is a great building block for many, run-of-the-mill services (e.g. no GPU, not crazy resource usages).

- Lambda is incredibly useful as glue between systems. I use Lambda to connect S3, SES, CloudWatch, and SQS to application code. I've also gone without Lambda on the SQS side and written my framework layers to dispatch messages to application code. This has advantages (e.g. finer-grain backoff control) but isn't worth it for smaller projects.

- Secrets manager is a nice foundational component. There are alternatives out there, but it integrates so well with ECS that I rarely consider them.

- RDS is terrific. In a past life, I spent time writing database failover logic and it was way too hard to get right consistently. I love not having to think about it. Plus encryption, backup, and monitoring are all batteries included.

- VPC networking is essential. I've seen too many setups that just use the default VPC and run an EC2 instance on a public IP. The horror.

- I've recently started to appreciate the value of Step Functions. When I write distributed systems, I tend to end up with a number of discrete components that each handle one part of a problem domain. This works, but creates understandability problems. I don't love writing Step Functions using a JSON grammar that isn't easy to test locally, but I find that the visibility they offer in terms of tracing a workflow is very nice.

- CloudFront isn't the best CDN, but it is often good enough. I tend to use it for frontend application hosting (along with S3, Route53, and ACM).

- CloudWatch is hard to avoid, though I rather dislike it. CloudWatch rules are useful for implementing cron-like triggers and detecting events in AWS systems, for example knowing whether EC2 failed to provision spot capacity.

- I have mixed feeling about DynamoDB as well. It offers a nice set of primitives and is often easier to starting use for small projects than something like RDS, but I rarely operate at the scales where it's a better solution than something like RDS PostgreSQL with all the terrific libraries and frameworks that work with it.

- At some scale, you want to segregate AWS resources across different accounts, usually with SSO and some level of automated provisioning. You can't escape IAM here and Control Tower is a pretty nice solution element as well.

I'm not sure if I'm up to 20 services yet, but it's probably close enough to answer your question. There are better and worse services out there, but you can get a lot of business value by making the right trade-offs, both because you get something that would be hard to build with the same level of reliability and security and because you can spend your time writing software that speaks more directly to product needs.

As for "having a fantastic time", YMMV. I am a huge fan of Terraform and tend to enjoy developing at that level. The solutions I've built provide building blocks for development teams who mostly don't have to think about the services.

jasode• 6 years ago

I would also be interested to hear the other side of the coin. Who out there is using 20+ AWS/Azure/GCP products to back a single business app and is having a fantastic time of it?

Netflix uses a lot of AWS higher-level services beyond the basics of EC2 + S3. Netflix definitely doesn't restrict its use of AWS to only be a "dumb data center". Across various tech presentations by Netflix engineers, I count at least 17 AWS services they use.

+ EC2, S3, RDS, DynamoDB, EMR, ELB, Redshift, Lambda, Kinesis, VPC, Route 53, CloudTrail, CloudWatch, SQS, SES, ECS, SimpleDB, <probably many more>.

I think we can assume they use 20+ AWS services.

p_l2• 6 years ago

Certain services IMHO have to be discounted from this list:

- VPC - basic building block for any AWS-based infra that isn't ancient

- CloudTrail - only way to get audit logs out of AWS, no matter what you feed them into

- CloudWatch - similar with CloudTrail, many things (but not all) will log to CloudWatch, and if you use your own log infra you'll have to pull from it. Also necessary for metrics.

- ELB/ELBv2/NLB/ALB - for many reasons they are often the only ways to pull traffic to your services deployed on AWS. Yes, you can sometimes do it another way around, but you have high chances of feeling the pain.

My personal typical set for AWS is EC2, RDS, all the VPC/ELB/NLB/ALB stack, Route53, CloudTrail + CloudWatch. S3 and RDS as needed, as both are easily moved elsewhere.

mumblemumble4• 6 years ago

I recently inherited a product that was developed from the ground up on AWS. It's been a real eye opener.

Yes, it absolutely is locked in, and will never run on anything but AWS. That doesn't surprise me. What surprises me is all of the unnecessary complexity. It's one big Rube Goldberg contraption, stringing together different AWS products, with a great deal of "tool in search of problem" syndrome for good measure. I am pretty sure that, in at least a few spots, the glue code used to plug into Amazon XYZ amounted to a greater development and maintenance burden than a homegrown module for solving the same problem would have been.

NIH syndrome is certainly not any fun. But IH syndrome seems to be no better.

bird_monster7• 6 years ago

There is no value to our customers in us stringing together a pile of someone else's products

Maybe not your business, but there are many businesses in which this is exactly what happens. Any managed-service is just combining other people's work into a "product" that gets sold to customers. And that's great! AWS has a staggering amount of products, and lots of business don't even want to have to care about AWS.

Who out there is using 20+ AWS/Azure/GCP products to back a single business app and is having a fantastic time of it?

Several times. I think cloud products are just tools to get you further along in your business. Most of the tools I use are distributed systems tools, because I don't want to have to own them, and container runtimes/datastores. Every single thing I've ever deployed across AWS/Azure is used as a generic interface that could be replaced relatively easily if necessary, and I've used Terraform to manage my infrastructure creation/deployment process, so that I can swap resources in and out without having to change tech.

If, for some reason, Azure Event Hub stopped providing what we needed it for, we could certainly deploy a customized Kafka implementation and have the rest of our code not really know or care, but from when we set out to build our products, that has always been a "If we need to" problem, and we've never needed to.

notretarded• 6 years ago

I'm in two minds about this (deeper integration with a particular vendor - i.e. "serverless")

Reduced time to market is incredibly valuable. Current client base is well in its millions. Ability to test to few and roll out to many instantly is invaluable. You no longer have to hire competent software developers who understand all patterns and practices to make scalable code and infrastructure. Just need them to work on a particular unit or function.

The thing which scares me is, some of these companies are decades of years old, hundreds. How long has AWS/GCP/Azure abstractions been around for? How quick are we to graveyard some of these platforms. Quite. A lot quicker than you can lift, shift and rewrite your solution to elsewhere.

g9yuayon• 6 years ago

So your company cautiously chooses which services in AWS to use, and sticks to infrastructure offerings for now. Netflix called it "paved path", and it worked really well too for Netflix. Over the years, though, the "paved path" expanded and extended to more services. It's worth noting that EC2 alone is a huge productivity booster, bar none. Nothing beats setting up a cluster of machines, with a few clicks, that auto scales per dynamic scaling policies. In contrast, Uber couldn't do this for at least 5 years, and their docker-based cluster system is a crippled for not supporting the damn persistent volumes. God knows how much productivity was lost because of the bogus reasons Uber had for not going to cloud.

mycall• 6 years ago

Did you look into multi-cloud solutions like Pulumi or Terraform to abstract your cloud vendor?

tiew9Vii• 6 years ago

Don't fall for that trap.

I have never used Pulumi, I've used Terraform a bit. I like Terraform so this isn't a dig at the tools.

Abstracting your cloud provider is similar to abstracting your database. At a high-level they appear to be the same, they do similar things however the are very different when you get to the fine detail.

Pulmi / Terraform are useful in the provide a common language / API between cloud providers however you will never just switch cloud provider with changing a few lines of code.

twistedpair3• 6 years ago

It depends on your company. For new startups, I'd stick with delivering your product over building your own cloud services on top of EC2/S3.

At my last startup, the engineering head shared the Not-Invented-Here view. We couldn't use any handy services. We had to run our own Cassandra and everything else services. It was a huge time sink for a small team that didn't deliver differentiating value.

At my current startup, we're almost 100% serverless on SaaS providers. We operate a thousand or more nodes with no ops team (a couple engineers know ops, when needed). We leave the complexity of scaling an maintenance to our cloud vendor's autoscaling services. Sure, we could reduce our opex in places by trying to roll our own, but the ability to have the vast majority of engineers delivering customer product, rather than reinventing the wheel is more valuable to us than fear of vendor lock-in. If our cloud vendor wanted to jack rates, we'd take the necessary action, which we've done before when we banged a service in a week that a vendor was going to hold us over a barrel for, then dropped the vendor.

MaxBarraclough• 6 years ago

The one time somebody tries to use some managed service that goes overbudget by 3000%, and the after action figures out that it would have been within the budget by using <open source technology> in EC2, they just do that instead

This impacts casual dabblers too. More than once I've seen HN comments on how someone is wary to experiment with cloud computing because a single screw-up can lead to an essentially unlimited bill. Judging by HackerNews anecdotes of when this does happen (unexpected overruns of thousands of dollars), there's a reasonable chance Amazon will refund you out of good will, but that's not enough to lay the fears to rest.

Linode let you pre-pay, for instance, but (to my knowledge) this isn't an option offered by Amazon, Microsoft, or Google.

ak2172• 6 years ago

You seem to have made up your mind, but for the benefit of others: yes, we use many AWS products and are having a fantastic time of it. AWS services are more reliable, less buggy and have more stable APIs than any of the alternatives. Specific services that made a difference to us are Fargate, Spot, Batch, SQS/SNS, Lambda, ECR, EFS, ELB/ACM, CloudWatch Logs, IAM, Aurora RDS, SSM/Secrets Manager, and Step Functions - in addition to EC2/VPC/EBS, Route53 and S3 that you already listed. Each of these services does a lot to free us up to do more value added domain-specific work.

Terraform has emerged as a key tool to manage AWS resources - so much so that it really adds a lot to the value prop of AWS itself. I can do stuff with Terraform that was only aspirational until it existed.

Personally, I wouldn't plan on using on-prem except for niche applications that involve heavy data streams from local hardware. In the time that I've spent with companies working on AWS, I've seen a number of other companies waste lots of time and resources on heterogeneous strategies while complaining about their AWS bill - which was high because someone got so fed up with IT dysfunction, they went and used AWS but left behind inefficiently configured resources that were on all the time. Cloud often ends up being an escape hatch for teams that are not adequately served by dogmatic IT departments.

dimitrios1• 6 years ago

The key glue to a lot of what you mentioned missing in your list to make a lot of this work for outside consumers: API Gateway, arguably their worst product.

hinkley2• 6 years ago

Given the situation with Amazon Essentials, anyone who sells a product made substantially of stringing together AWS technology may find themselves cut out of the picture soon enough.

Many other companies have ended up competing with their own vendors. The only thing unique about Amazon is that they are boiling the frog much more slowly than previous generations of companies have.

s3tz• 6 years ago

Anyone manage to find part 1? It's not on their site, can't seem to find it.

jvanderbot2• 6 years ago

It's linked in the article https://ea.rna.nl/2016/01/10/a-tale-of-application-rationali...

"This was actually part 1 of this story: A tale of application rationalisation (not)."

CalChris• 6 years ago

Isn't this just Jevon's Paradox applied to software?

  when technological progress ... increases the efficiency with which a resource is used .., but the rate of consumption of that resource rises due to increasing demand [1]

[1] https://en.wikipedia.org/wiki/Jevons_paradox

mrkramer2• 6 years ago

Microsoft summarized it nice [1] :

Advantages of public clouds:

Lower costs

No maintenance

Near-unlimited scalability

High reliability

Advantages of a private cloud:

More flexibility

More control

More scalability (compared to pure on-prem solution)

[1] https://azure.microsoft.com/en-us/overview/what-are-private-...

indymike• 6 years ago

Hmm... So Azure for unlimited scalability... But private clouds have more scalability?

beaconstudios• 6 years ago

Presumably both options are written relative to non cloud setups

8K832d7tNmiQ• 6 years ago

probably meant that you can just request hundreds of servers in other part of the world in one single setup compared to manually building your server there.

cccc4all• 6 years ago

Notice that neither list has "Reduce Complexity" as benefit.

Cloud can abstract away complexity. Shift managing the complexity behind the cloud. But, it's more likely that complexity increases rather than decreases.

jvanderbot2• 6 years ago

Part 1 is linked in article

https://ea.rna.nl/2016/01/10/a-tale-of-application-rationali...

"This was actually part 1 of this story: A tale of application rationalisation (not)."

arendtio• 6 years ago

I wonder who tells the story that cloud computing has something to do with reducing complexity. In my world, cloud computing is a bout scalability and making things as complex as they need to be to be scalable. This rarely means that complexity is being reduced.

didericis2• 6 years ago

The simplicity of having one cloud based product rather than several native products built for different systems is an argument I’ve heard a lot.

ratww5• 6 years ago

This is an advantage of the web platform, not exactly related to cloud. You can get this advantage with an on-premises web product, or with old school hosting.

twistedpair3• 6 years ago

But doesn't cloud computing reduce complexity? I used to write my own SystemV boot scripts, service installation and discovery logic, round robin updating tooling, and much more to handle live app deploy/cut over.

Now I have two dozen lines of YAML and GKE JustWorks™, deploying my services and taking care of everything I used to do with my bespoke scripts. My world is much simpler now.

candiddevmike• 6 years ago

I see a lot of mentions in the comments about just using the basic storage/networking/compute from AWS/AZ/GCP--if that's all you're using, you should really consider other providers. Linode, Digital Ocean, and Vultr will be far more competitive and offer faster machines, cheaper, and with better bandwidth pricing.

The point of using AWS/AZ/GCP is to leverage their managed service portfolio and be locked in. If you aren't doing that, there are better companies that want your business and will treat you much better.

ithrow2• 6 years ago

IME, the network of AWS is much better than that of DO, Linode.

dilyevsky5• 6 years ago

How so?

dilyevsky5• 6 years ago

There’s also packet (now equinix metal) that gives control over l2 and have nice things such as ibgp. I think vultr may do too but their docs are poor and support was uncooperative

marvinblum• 6 years ago

This. I switched to Hetzner Cloud and reduced costs from ~$200/month on GCP to about ~20€/month. For comparison: 1cpu 2gb ram cost about $15 on GCP and 2,50€ on Hetzner, 1gb outgoing traffic ~0,12€ -> 20TB per machine included on Hetzner and 1€ per additional TB.

I'm still using S3 and GCS to store files because it's convenient and relatively cheap.

tasogare• 6 years ago

This. And also AWS showed they can delete your business infrastructure unilaterally, without notice, on a whim so it’s very risky to use them.

Aeolun2• 6 years ago

AWS has like 10 times more regions than any of the alternatives. If you want something close to home AWS is best.

malinens• 6 years ago

very very few need so many regions to choose from

skohan2• 6 years ago

I have to say, at my current company we are using Serverless, and it really does feel like it reduces complexity. No runtime/framework to set up, no uptime monitoring or management required on the application layer, and scaling is essentially solved for us. I mean you do pay for what you get, but it does feel like one of those technologies which really lowers the barrier to entry in terms of being able to release a production web application. In terms of building an MVP, a single developer really can deploy an application without any dev-ops support, and it will serve 10 million users if you manage to get that much traffic.

I'm sure it's not optimal for every case, but for an awful lot of cases it seems pretty darned good, and you can save on dev ops hiring.

ratww5• 6 years ago

I used to be very excited about serverless, and I still have high hopes for it.

But for me it ended up replacing the complexity of runtime and frameworks with the complexity of configuring auxiliary srevices like Gateway API, Amazon VPC, etc. We needed to move the complexity to some tool that configured the services around Lambda, like Terraform or Cloud Formation, or at best to a framework like Claudia or Serverless.com. Configuring it by hand looks fine in tutorials, but is madness: it's still complex, and makes it all way too fragile.

There are however some products that make the experience better by simplifying configuration, like Vercel and Netlify.

skohan2• 6 years ago

Yeah I certainly agree that the complexity doesn't really go away completely, and sometimes it's much more frustrating to have to configure poorly documented services rather than just having access to the host OS.

I guess my overall point would be that two of the hardest things to do in terms of making a production-ready application are scaling and security, and Serverless pretty much obviates them. So it's not a magic wand, but it does take away some of the significant barriers to entry.

8note• 6 years ago

I was expecting writing serverless to be a mess of writing configuration, but I've really enjoyed writing CDK for cloudformation. It's super unclear how you're supposed to write good cdk code, but I feel like I'm a lot clearer on what infrastructure I'm actually using than before, where I was relying on stuff set up by someone else ages ago with minimal to no documentation

ehnto• 6 years ago

I don't understand what people are building in order to need half of this decoupled and managed elsewhere anyway. It wasn't all that challenging to self manage it five years ago, what's changed?

My guess is that the average small to medium project has drank the enterprise coolaid, and they are suffering the configuration and complexity nightmares that surround managing cloud infrastructure before they really needed to.

As the article is pointing out, you don't forgo managing these things by doing it in the cloud, you just manage it inside a constantly changing Web UI instead of something likely familiar to your developers.

ratww5• 6 years ago

There are products (Terraform, CloudFormation) that help managing without an UI, but they also add complexity, so our point definitely stills stands.

dijit3• 6 years ago

I've used Terraform for 4~ years.

the providers are ever changing (and so is the terraform language/features). So the "ever-changing" part is certainly still true for Terraform.

dkarl• 6 years ago

I guess it's Kool-Aid? I don't know; I don't remember being lied to when I started using cloud services. I think of cloud resources as being amazing and basically magical, but I know there's a limit to the magic, and the rest is work. People using (for example) AWS S3 should not be surprised that they still have to work to manage the naming, organization, access control, encryption, retention, etc. of their data, and they might encounter problems if they try to load a 100GB S3 object into a byte array in a container provisioned with 1GB of RAM. But they are. I don't know if that's human nature or if they're being lied to by consultants and marketers.

nelsonenzo2• 6 years ago

This person has never worked in a data center. He thinks he's managing a network because he sets a few vpc ips, that's an itsy tiny fragment of networking, and the cloud has indeed removex a great deal you previously had to manage on prem.

rubatuga• 6 years ago

I'm guessing you mean things like STP, firewalls, rate-limiting, routing, DHCP, and link aggregation?

LimaBearz• 6 years ago

Or going back even further I started my career worrying about all that, plus HVAC, hardware acquisition, capacity planning, power management, distribution and managing gensets(fuel and maintenance); and all the fun crap associated with it like a burst water pipe in your data center on Christmas Eve

nelsonenzo2• 6 years ago

to start, yes :)

zoomablemind• 6 years ago

Subjectively, it increasingly feels that while the complexity has been increasing, the notion of longevity of the underlying products and services has been degrading.

While updates to software were expected, general outlook would be that they would not be breaking the core features. The emphasis on backwards compatibility was in a way an assurance to businesses that building their operations on vendor's products is not risky. Even then, some mission-critical elements would be defensively abstracted to avoid the dependency risks (at least theoretically...)

Now, we all witness the "eternal-beta" paradigm across the most of the major software products. Frequent builds with automatic updates, when new features could be suddenly pushed, and old features removed.

Sure, it's still possible to spec out a "hard-rock" steady platform, postpone updates, abstract dependencies and just focus on business. But...such approach won't be approved, as it's widely acknowledged that the presence of critical bugs is rather a "feature" of all software. Postponing the updates is not prudent, it's a liability.

So the rock-solid expectations are just an illusion or perhaps a fantasy promoted widely, just to get the foot in the door.

Ironically, the most stable elements are the so much dreaded "legacy", too often in charge of the business-critical logic.

twistedpair3• 6 years ago

the notion of longevity of the underlying products and services has been degrading.

Is eternal longevity even a relevant concept in computing ops any more?

I think businesses must grok that all services are living things that will require eventual maintenance. If you roll your own service, eventually the OS, even an LTS, will need upgrading when the prior release goes EOL. If you're higher up on a FaaS, the language/runtime will still age out, like Python 2, Node.js 6, or Java 5. These will inevitably come with changes. You application will need to adapt.

In extreme cases you can pay for ancient language support and customer IBM mainframe hardware, but the reality is the software's hosting will always need to be updated as time marches on.

bdavis__• 6 years ago

Kind of depends on "eternal". I propose 10 years is possible, and realistic. 5 years should not be rare. 20 years is probably a fantasy.

blabitty• 6 years ago

For simple document or file type storage for an application I think solutions like S3 or azure blob storage are really great. In my real world experience we replaced a highly finicky way too heavyweight COTS CMS and all the associated database and backend SAN complexity with S3 and it ended up being way cheaper, easier and more reliable. To me object storage is one place where the cloud hype does deliver. Have had mixed results with the other services, even with things like RDS you have to do a lot of tuning and backup / DR work yourself.

The many lies about reducing complexity part 2: Cloud

Related Stories