Interview with a Head of Business Development Department at Opsworks Co., Victor Atamanenko. He breaks down all myths around DevOps and its benefit to the business.

Millions of tech startups are hitting the market every year. Most of them fail due to no market match. The survivors usually offer products or services that make our life easier or help other businesses grow revenue. At the end of the day, all of them are all trying to make money.

The truth is that most of the apps on the market have monolithic architectures because:

It’s easier to develop;
It’s cheaper to develop;
There is no need for scaling.
So, why microservices are buzzing in the tech world and what kind of companies need them?

We did an extensive interview with Viktor Atamanenko, a Head of the Business Development Department at OpsWorks Co., to give you all the answers. What companies need to look up the microservice architecture; will it benefit their business and how; are microservices worth the trouble — read on and find out!

Certainly. First of all, tech business owners have to realize that no infrastructure is perfect and they’d better be aware of its pains. If someone thinks DevOps is a magic pill that you take and the problem fades — no, you’ve been fooled by tirelessly working sales and marketing departments of DevOps companies.

DevOps solves three main issues:

– infrastructure/personnel maintenance expenses optimization
– development expenses optimization
– downtime

Actually, the last bullet includes infrastructure reliability, scalability, etc. Our clients usually come to us with the same issues. In particular, the ones I’ve named.

There are certain technologies and methodologies that help our clients solve their business issues and concentrate on growing their company rather than trying to bail water out faster than it’s coming in. Business owners don’t have to think about how to make their infrastructure function — they hire a team of engineers for this. In a perfect scenario, the team teaches machines to do it for them.

As I said earlier, DevOps solves three issues: infrastructure maintenance, development optimization, and downtime. I’ll try to give a detailed tour of those three for you!

So, let’s imagine I own an online marketplace and I host it on the dedicated servers, for example, Hetzner. I have to maintain thousands of personal cabinets in the daytime, but I don’t want to pay extra for maintenance at night. Especially, if it’s almost half of the price I pay for daily maintenance. See, the problem with physical servers is that I can’t lease a Virtual Machine, I have to pay for the whole server. In case I need a little more capacity than one server offers, I’ll need to lease the two of them. Of course, I can set up an automatic scale up and down on the physical server. However, I will need to control the capacity.

Nobody wants to pay for air, right? I want to pay only for the power used when my system was active. For this reason, I would rather migrate to the cloud, pay only for the used capacity, and scale to whatever size I want and when I need to.

Regarding development optimization with DevOps practices has been said so much, yet, I will never get tired of explaining the benefits of CI/CD for the development process. It all starts at the quality assurance stage: the two weeks old code gets checked and this is where all these bugs and breakdowns start — right before the release, of course. This is when you can smell a hotfix in the office.

Now, every tech startup and big enterprise can avoid worrying before the release simply adopting a CI/CD approach. Continuous integration/delivery means that every commit of the code will be instantly integrated into the test environment. Then Jenkins compiles the commit with the rest of the system. In just a moment you know if the system operates with the existing code. If not, you’ll know what part of the code needs improvement.

Also, the majority of our clients’ initial goal is to increase uptime. It means that their website and the system frequently goes down and users can’t access it. This results in negative user experience and, therefore, fewer clients.

DevOps offers businesses to avoid downtime by adopting an auto backup system that lets you roll back to the previous version of the software in case a new commit disrupts the workflow. Check the example of its realization here.

Well, probably, the main one is Iac (Infrastructure as Code). Simply saying, it is an approach that lets you automate your infrastructure with scripts. However, developing an IaC infrastructure is a bit time-consuming. Let’s say, you manage an online shop hosted on two Virtual Machines in the cloud. You have in average 100 new personal cabinets created every day. To prevent your system from failing on Black Friday, you’ll have to create the third VM with the same software and configuration for a sudden traffic peak.

You’ll spend several hours doing it manually — quicker than developing dozens of scripts for the processes automation. However, when the IaC infrastructure is ready, creating a new VM will take you around 5 minutes. Four hours vs. five minutes is inspiring, isn’t it? Moreover, you won’t even need to think about possible system failures — the script will create another VM with the needed software when the load is peaking.

Also, it is much easier and less time-consuming to manage an IaC infrastructure. Need one more identical VM? Press the button! Don’t need it anymore? Press the other button! Simple as this!

Nowadays, business owners aim at developing online services rather than applications as it takes less time. Therefore, it brings more revenue. Requirements for online services are much higher than to products. They have to be highly available, dependable, and easily scalable. Because each customer gets a product, but thousands of customers use the same service simultaneously and you never know how many customers you will have in five minutes. The infrastructure should be flexible and fault-tolerant. This kind of services value reaction time the most. This is why a customer would rather leave you for another service instead of waiting for four hours until you create a new VM to spread the load.

No, not necessarily. Both cloud and so-called “ground” (physical servers) have their advantages and disadvantages.

As for the “ground” — hosting on the physical servers requires significant seed funding; servers maintenance (energy consumption, ventilation and conditioning system) costs a fortune.

Regarding the disadvantages of the cloud…well, here I can point the biggest concern of the clients — security. Even though big cloud providers have more resources to update the servers and keep them in the environment that meets maintenance requirements, very few financial institutions migrate to the cloud due to the critical data.

And specifically for security reason governmental institutions or financial firms do not place their infrastructures in the cloud. Moreover, there’s always GDPR and data protection laws that may restrict relying fragile data on third parties. So, banks, online exchanges, etc., may go cloud, but user information should be stored on their servers in the country they are based.

Cloud providers offer more and more benefits for the business. This is why companies move everything except for the critical data to the cloud.

Although the combination of DevOps and microservices has the potential to yield tremendous benefits to organizations and their teams, enterprises should still invest in a platform strategy to ensure everyone in Development and Operations can take advantage of these technologies.

A platform strategy doesn’t necessarily just refer to any underlying hardware and operating system/s. It also involves all software application developers build and run on, including the OS, cloud technologies, storage, and middleware framework. Setting up a platform also ensures that your microservices have an established base to scale out from without straining the organization.

In addition, the automation of tests, the delivery pipeline (for continuous flow), provisioning, and cloud sandboxes, help speed up the production process.

Bottom line? The evolution of microservices architectures and DevOps in the enterprise only helps organizations achieve their objectives and goals, all while staying ahead (or keeping up) with their competitors. Microservices and DevOps perfectly complement each other, speed up adoption, and encourage experimentation—things any business can benefit from.

It is! But it’s not always beneficial. Building a microservice architecture involves writing an excessive code. Regarding the development process, your life is simpler if you don’t have to create a microservice architecture. It’s much longer and more difficult than creating a monolithic app.

Yes. Usually, every app starts with a monolith. When shifting to microservices you need to:

– split the whole app into separate and independent modules
– build interaction mechanisms between the modules (API)

It’s always required to review the client’s business to understand if the microservice infrastructure will benefit or harm it.

These are systems that need to be easily scalable and have a highly volatile load. For example, today your website has 5K users, and tomorrow it’s 20 million. A monolith architecture will not bear this kind of spike. If your app is a monolith, you’ll need to scale the whole infrastructure. In microservices — only the service that is being used the most. Moreover, microservices can be scaled automatically when there is a need for it.

What concerns scaling, yes. However, DevOps also offers a zero-downtime update. Let’s imagine, you operate an app and you need to roll out an update. To do this, you will need to shut the system down. Meanwhile, your users are not able to use the service. You don’t want this, right?

A zero-downtime update means creating an identical to a production environment that implements a new feature first. If the functionality survives the new code, the following environment becomes the main, so that you don’t get downtime at all.

This becomes critical when we talk about financial services because every minute when the system is down you lose thousands or even millions of dollars. Imagine the situation: you’re driving home, stop by a gas station to refuel and have some snacks. You try to use your card to pay…oops…your bank is updating the system — the service is not available at the moment. It’s ok if you have enough cash, but what if you don’t?

Also, if downtime is a big ‘no-no’ for your system and it causes damages to business, consider one more thing: “If a monolithic app fails, it fails ultimately. If there is a fail in the microservice app, it is local and doesn’t cause an entire system failure.”

So, if one service in the monolithic payment system fails, the whole system doesn’t work. If one service in the monolithic app stops functioning, the whole system continues working. To have such a benefit our clients develop excessive code.

Well, code optimization is one of the business tasks, but DevOps has nothing in common with code optimization, it gives businesses an ability to develop. Let’s take, for example, modern business models. There are a lot of companies whose business model drastically differs from the giants on the market. I’m talking about companies like Uber/Uber Eats or streaming platforms like Netflix. What connects them all is no strategy. They build products in the request to the user’s demand. Their goal is to give the users what they want and do it very fast. They see demand, develop a product and launch it on their platform. This is what DevOps does — helps programmers create a quality product fast and roll it out to the prod. Time is money as they say!

Ask us questions at sales@opsworks.co or find out more on our blog!