06.05, Katowice AWS Summit Poland
7 min readPart 1/4

Decisions in a world where computing is commoditized

Why have we picked particular solutions? Which points were crucial for a newly launched startup?

This series is going to lead you down the path of responsible choices, designs and snippets of code that, in overall, decrease initial costs, shorten time to value, set a baseline for higher pace of future improvements and, last but not least, “simplify” maintenance (I’ll explain later why I’ve put this word in quotation marks).

In this post, we’re going to discuss why we’ve picked particular solutions, and which points were crucial from the perspective of a newly launched startup.

Got an idea for an application

In the Q4 of last year, I met an old friend of mine who came up with a new application idea, which had its first production release in 3 months’ time. He had already prepared the entire high-level design, so we sat together and started to match technology to his goals. Basically, we selected the following topics we wanted to cover, and decisions that needed to be taken:

Project due date = 3 months for time to value

After many years of cooperation with different kinds of customers, I’ve learned one valuable lesson. Time is always the top priority. Everybody is forced to provide new solutions within shorter periods of time, no matter what. First and foremost, we live in a world where each company that tries to launch new innovative products competes in a continuously growing market. And my friend’s case was no exception. To make it clear, you can treat this project not only as a newly launched startup but also as a side project within a huge enterprise, where a small team works at short notice.

Long time ago, I abstracted myself from being a person addicted to a single solution, glorified by others. Now, when I approach new case, I always give myself space to consider different options (not necessarily the favorite ones) and find out the actual business value for my customers. Therefore, we highlighted points concerning time and budget that had to be taken into consideration:

CHOICE: 60% of time for non-cloud tasks, 40% for cloud infrastructure/development. “Serverless” was mentioned for the first time.

To be vendor locked or not to be

Nowadays, everyone is so afraid of being tied up with a single vendor, even outside the IT world. When we choose a microwave, a fridge, or a cooker, we constantly ask ourselves whether to match our new item to those we already have in our kitchens or maybe pick a new one, trusting a different manufacturer. In terms of cloud provider selection the decision is a little bit harder to make, but I firmly believe in the following point:

Of course, my point of view is biased but also pragmatic, because of the number of people I’ve got in my team. If you’re a huge multicloud partner, then your perspective might be completely different.

CHOICE: “single-cloud”

So many options hidden behind buzzwords

Instances, containers, serverless… these words are generally mentioned in every conference and meetup, promising you seamless implementations and utopia without any problems. However, these really great tools are abstractions onto the cloud ecosystem. In my opinion, the problemis that the community has grown up around these buzzwords, instead of unsolved problems, which, at the end of the day, moves us away from proper cloud thinking.

Having the project goals defined, we quickly selected the right option (for us). Logical, bounded context and a majority of request patterns based on events didn’t leave any doubts about choosing a serverless approach.

It’s considered that the people who follow serverless ideas first are those who have been doing cloud-based developments for a long time.The company was set up 2 years ago, and even though we had spent previous years inside the on-premise ecosystem, we haven’t lost the sense of selecting solutions that reduce complexity, especially when developing in the cloud. Therefore, we picked up serverless instead of containers or instances because of following requirements:

Some of you may say that it was feasible to meet the requirements with all 3 solutions (instances, containers, serverless), and I say, “YES, you’re absolutely right.” The point is that the business value didn’t come from the infrastructure but the “non-cloud-related” code prepared by devs. We presented the customer with the value he wanted: “No processing = no payment.”

CHOICE: “serverless”

Future is just behind the corner, just after the first production release

This one is going to be short. If you’re a business goal-oriented company that understands pay-per-invocation model, and you want to bring new improvements quicker (time to value) then basically serverless is the right choice, unless:

I’m going to let you decide this point by yourself because some companies are able to keep launching new features ahead of their competition without serverless infrastructure, but at what cost?

The lifecycle of the managed objects - Day 2

At the beginning of this article, I highlighted the “simplified maintenance” expression I used intentionally and promised you that I will come back to it later. So, let me explain the reduction of complexity I had in mind when we were recommending serverless as a one-and-only path for this project. Whenever I listen to rumors about how the serverless ecosystem simplified the Operations role, I cannot deny the mindset break through we experienced after launching our products on serverless architecture for the first time.

Once I’ve heard that “cloud allows inexperienced people to do something that previously only experienced people could do.”

Today, I would modify it and say: “Serverless allows those inexperienced in networking/infrastructure to do something that previously only experienced people could do". And that’s the point. We live in the century in which developers are able to set up the whole application without Ops, but… Remember that devil is in details, and if something is hidden and simplified, it doesn’t mean it should be taken for granted. That’s what I explained to the customer - devs have to code and release new features, not take care of scalability, performance and cost optimization. Serverless provides “simplified maintenance” and I have no faith in the “no Ops” version. What I do believe in is Ops being moved toward application performance and cost optimization tasks based on events/requests, far away from repeatable chores like patching, scaling, setting up new clusters, etc.

OUTCOME: Serverless provides a lot out of the box solutions and redirects our “Ops” activities toward new areas

End of Chapter 1

This is the end of Part 1. Hopefully, it brought you some digestible answers and dispelled doubts which not only our customer, but many of you might have had. After analyzing the pros and cons, we collectively decided to build a project on top of serverless services. In the next parts, we’ll focus on the examples.

So, let’s set a course and navigate new waters of design and code.

Let's talk about your project

We'd love to answer your questions and help you thrive in the cloud.