Decisions in a world where computing is commoditized

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 project's time to market, set a base line 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:

• time to market vs. budget
• single-cloud, multi-cloud
• instances, containers or serverless
• future improvements
• management

Project due date = 3 months for time to market

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:

• the customer hasn't got DevOps fleet that know or is able to master Docker, Kubernetes as well as IaC tooling from Day 1
• limited budget to spend at this stage (photo)
• cloud infrastructure covering 40% of total requirements. Additional time for developers needed for non-cloud related coding (remember about the limited team)
• release of a product that follows the pattern of "bounded contexts" and "loosely coupled services", in other words, architecture divided into microservices
• within this budget, the customer wanted to maximize resilience to failures

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:

• the single-cloud selection allows you to dive deeper and extract more features from services with a better understanding of potential issues.

NOTE: 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 multi-cloud partner, then maybe you'll look at this problem from a completely different angle.

• from a customer's perspective single-cloud approach, especially in its first years of existence, allows people to stay focused on business goals and spend more time on tuning tools, monitoring the provider's ecosystem with its support team and workshops.
• last point in this section - people. You'll need to have them on board for further development and maintenance (Day 2), either in the form of one or multiple cloud providers. Provided you find those (I'm sure you will), ask yourself if you need a Jack of all trades or master of none, and whether the abstraction level they've got is ok or you.

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:

• requests pattern (managed to design it as event-driven)
• no Ops employee(s) inside customer's structures
• application business model ideally designed for pay-as-you-grow
• short-lived tasks in the first part, as per design
• "I want to test/receive data/analyze my hypothesis for as low price as possible" customer
• developers prepare code not directly related to the cloud and have to be abstracted from cloud components if possible
• "I want to be prepared for a greater scale and high availability in the future"

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-market) then basically serverless is the right choice, unless:

• you've got top-tier Ops team taking care of your highly scalable infrastructure
• you don't mind paying for DevOps recruitment processes instead of on the product

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 its hould 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.