paint-brush
Complicated Simplicity: The curse of modern tech.by@joey.clover
1,172 reads
1,172 reads

Complicated Simplicity: The curse of modern tech.

by Joey CloverSeptember 27th, 2018
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

You’ve heard all about these deceptive creatures. They promised you whatever you wanted – which for the sake of this article is the perfect server <a href="https://hackernoon.com/tagged/architecture" target="_blank">architecture</a> for your applications. However, they didn’t tell you that you would also be cursed by the very thing you were granted. That’s right, we are talking about Micro-services and Server-less.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Complicated Simplicity: The curse of modern tech.
Joey Clover HackerNoon profile picture

You’ve heard all about these deceptive creatures. They promised you whatever you wanted – which for the sake of this article is the perfect server architecture for your applications. However, they didn’t tell you that you would also be cursed by the very thing you were granted. That’s right, we are talking about Micro-services and Server-less.

Question: Do you think that these technologies are wrongly over-inflating their value or do you think that it’s acceptable marketing?

The Micro-service Promise

So, you stumbled across micro-services one day and you were told that not only could you reduce costs for your applications but you could scale independent units depending on their load. You have a “payment” service that gets hammered? Sure, scale that up and leave your “authentication” service running at a lower cost.

So, you’re happy with this but you realise that it’s added some time with all of this JSON jumping between servers so you’re offered another solution. Here’s gRPC. Binary data firing across services with almost instantaneous decoding and encoding.

Oh no! I need to change my User model to track the most recent payment made.

Easy, right? You just have to change the model and deploy. Nope. You’ll have to make sure all your dependencies are up to date on the “authentication” service and the “payment” service and make sure that you’re all versioned up.

Oh no! We need to understand what’s happening across our servers and monitor the status of each service.

Easy, right? Nope. You’ll quickly find yourself installing a “sidecar” alongside every service and having to ensure that the sidecar itself is working and functional.

Micro-services have flaunted around calling themselves simple, cost-effective and efficient. Realistically, if you’re not getting millions of hits on a daily basis, this is almost entirely untrue and you’ll easily waste more time and effort investing into the architecture.

So, micro-services turned out to be a bit of a deception. They certainly have value but they’re not for many companies. What about lady server-less?

The Server-less Promise

Server-less advertises similar benefits to Micro-services although the cost-saving factor is pushed to the extreme as you’re not paying for any line of code that isn’t being executed. Server-less offers extremely flexible scaling and convenience.

Once you start looking at these architectures from a base level, it’s already intimidating and has extreme boilerplate to get set up. I’ll use AWS Lambda in these examples but from experience, all have a painful learning curve.

So, you get your thinking cap on and learn AWS SAM and create a handy resource file to kickstart your architecture. It’s horrible to maintain though and it’s clearly not worth the benefits.

I just heard about the Server-less framework that promises deployment across any provider in a single command!

Great, so you download Serverless and get cracking. You decide to run the initialisation command, edit your config file and run deploy.

Server-less has gone and done a bunch of things that wasn’t very transparent. It’s created an entire stack, created a service in API Gateway for you, applied a few settings and pushed your lambdas up.

Now you need to decide whether you want a different AWS account for production or live, or you want to do a deep dive into IAM or you want to settle for two environments on one account. Then you learn about the 75GB limit and that they don’t automatically delete older lambdas.

Wow, I got my POST endpoints working and now I can create and edit a user!

Congratulations. Have you tested to see what happens when you need to return a 403. Do you have a consistent way to deliver errors across your platform? What about authenticating endpoints? You could create an authentication lambda but be careful deciding on the cache timing for it.

Where is the simplicity?

This isn’t a post designed to complain about these technologies. It’s to bring awareness to those who think that dropping their monolith would be a great idea.

My biggest issue is the false advertising. These architectures are shown to be easy, with the one click deployments and promises.

They don’t show you the pain you’ll have showing errors, monitoring these architectures, versioning then, maintaining them and scaling them.

We use a mixture of legacy Micro-services and newer Server-less functions in deployment and it works fine. We had a large number of teething issues and had to learn more about SAM to get almost any functionality that we used to take for granted in a monolith.

In conclusion, drop the complicated simplicity and stop deceiving people.