OMG, what is this, another article about how implementing DevOps will have an incredible impact on your business? Oh, wait, do not rush to conclusions because we have prepared something truly unique for you. In this article, we will show you what it takes to bring DevOps to your business — and walk you through it. Step by step, we will look at different approaches and possibilities, discover the pros and cons of each, and find ways to choose the best option based on the price-quality ratio for YOUR case. So, gentlemen, start your engines, we are going to show you how deep this rabbit hole is.

To begin with, it’s critically important to choose a tech stack ashore before developing your app.

Even the “will run anywhere since it’s Java Docker” scenario is better than nothing — it significantly narrows a potential list of platforms.

To choose or not to choose, that is the question for every Business when it comes to establishing the tech stack.

But the good news is that Corewide’s got you covered — this article aims to fill the tech expertise gap. We’ll highlight the pros and cons of various common platforms, solutions or approaches to help you map the course of action for your specific case.

Long story short: let’s speak about tech stack (our thing), budgeting and costs (your thing), and tech subtleties (our thing that influences your thing).

DevOps-as-a-Service & alternatives

The Devops-as-a-Service concept differs favourably from other operational models — and we’re just about to prove it.

It’s great if you’re Netflix — the flagship AWS client (and have signed an extremely beneficial contract). In this case, we can only thank you for your attention (and ask for a subscription 🤞). But what if you have a small/medium business aiming to reduce costs and efforts?

You may have faced PaaS so far, and it probably seemed pretty simple. You create an application focusing on the launch platform and pay to this platform, raising the plan with the complication of the setup.

Heroku comes to mind first and is an excellent example of PaaS:

+ it has an automated build system;

+ has a perfect connection with Git, which significantly facilitates the deployment;

+ provides an appropriate web interface for process control and basic configuration.

At the same time, we meet limited resources for a high price, which is unlikely can fit a modern application or microservice. The numbers speak for themselves:

+ standard 2X on Heroku — $50

+ the same size VM on DO (1 CPU, 1GB Memory / 25GB Storage / 1TB Bandwidth) — $5

+ VM on AWS — around $8.5.

For this overpayment, you get the preconfigured environments and real savings on system administrator / DevOps services. But it does not pay off at a long distance.

Another option is IaaS. This can be a good solution if you are ready to build the infrastructure in addition to the usual business processes. In this case, paying for computing resources, you get the freedom not to adjust your app to the infra; to some extent, you own your app data and know the setup’s details. The apparent disadvantage — you’ve failed to reduce your efforts.

Expanding the number of engineers (remembering they get sick or fired, and their management requires a separate unit) or outsourcing IaaS tasks to companies that offer such services can be a solution. The latter gives an experience similar to PaaS: vendor lock + opacity of processes.

After such a journey, all the advantages of DevOps-as-a-service are evident. You own the account and cloud resources and can see the actual costs, paying directly for cloud services. You also get the engineering team which adjusts the infra to your application’s needs.

With Corewide, you’ll get additional benefits:

+ predictable budget (fixed project scope and price);

+ autoscaling the team size without further intervention;

+ The Senior DevOps engineer, aka Architect, who arranges a team and supervises a task implementation.

This approach works for businesses of all sizes. But let’s focus on the scenario for startups. So,

Startups. How to end up screwing up

Long story short: the max result + minimum budget formula is often a failure over time. And now, to details.

Look at PaaS like Heroku or DigitalOcean App Platform. Both win clients’ hearts by hiding the infrastructure to some degree and offering nice price tags — but any setup complication leads to migration. If a business launches a simple one-component app, that’s an excellent choice — but Heroku and DO App Platform won’t cope with the rest. We faced the cases when a dozen devs had been writing microservices and deploying them to Heroku — the only project left on the platform is the one never developed.

AWS also offers numerous tools for uncorrupted startups. Taking the Amplify that claims to build, supervise, and clean everything instead of a DevOps team, in reality, it just deprives the control over processes and tries to replace non-AWS CI/CD.

Here goes our pro tip: you can create and automatically manage everything Amplify offers without a vendor lock or sudden pitfalls. And the earlier you do it — the better.

Another attractive alternative from AWS is called Lightsail and is known as a ‘big game for small money.’ Companies get preconfigured VMs with a widespread tech stack to develop and launch products right away. Moreover, smooth future scaling and migration to something significant like EC2 are promised. But Lightsail is not designed for customisations, so any step off the road makes you consider migrating (unplanned, as a rule) — a poor scenario for a small business eager to win clients’ loyalty. That’s why at Corewide, a single case when we deal with Lightsail is migrating from it.

If you’re afraid of sailing with gigantic AWS, jump into the small DigitalOcean — the water is fine. You won’t get the vaunted AWS or GCP ecosystem with hundreds of services but DO is plain, handy, and affordable, providing the EC2 and RDS analogues — Droplets и Managed Databases (but it’s, of course, not limited to these). The best part is that with DigitalOcean, you have an opportunity to grow without migrating. If you don’t seek specific services from other vendors, DO is what you need — it’s excellent at handling major setups.

Regardless of your chosen approach, Corewide is adept at the ‘thinking ahead’ theory. It implies that your initially chosen infrastructure offers a straightforward setup, clear workflow, and the possibility of scaling or migration in future.

There are also a couple of rare birds, such as the Bare Metal and Serverless (FaaS) approach. There are not so many reasons to choose them, so we will not dwell on them in detail here. However, if you are sure you need knowledge about them (or are just curious), feel free to follow the links because we have already written about them.

Meanwhile, we move on to the next stage, and this is

Containers-as-a-Service & Kubernetes

You build a container image, and the cloud runs it for you. Strict runtime environment, limited ports, difficult to build connections between several apps in the stack, and so on. You don’t get to tinker with the orchestrator, but you pay for the resources your container consumes. That is Containers-as-a-Service in three sentences.

What do major clouds have for CaaS?

Google AppEngine is probably the simplest CaaS with a clear list of restrictions and actual “pay as you go”. Scalability is a bonus. At the same time, the deployment is bound to use gcloud CLI commands. A real plus is the interactive debugging option to access the VM and troubleshoot a container directly.

AWS ECS can rightly be considered the most pumped CaaS option: it offers both Fargate (the typical “you specify the resources and replicas you need — we run them for you” method) and ECS EC2 (for DIY enthusiasts). Debugging-wise, the first option is too limited, while another is similar to AppEngine’s debug service. One exception: no pay-as-you-go for EC2. So the only real ECS bonus is not having to install Docker yourself. AWS API is supposed to simplify the management of ECS containers from the CI/CD pipeline. Still, in reality, it only makes it more cumbersome: you abandon your usual container toolkit to use AWS CLI to send long JSONs instead.

Azure Container Apps, Web Apps for Containers and Azure Container Instances work well only within the framework of Azure DevOps (hello, vendor-lock) and provide neither flexibility nor convenience. Three different ways of achieving the same, at varying success rates — in practice, they’re only suitable for genuinely abstract web microservices designed explicitly for this deployment method (e.g. API endpoints, stateless one-trick-pony microservices). For example, connecting a data volume is a problem for all Azure CaaS.

If the idea of CaaS is attractive enough for you, succumb to accepting vendor lock as an inevitability. Picking any of the services we covered will impact the architecture long-term, so understanding their features is crucial. In Corewide’s experience, a lack of functionality, CaaS limitations, or willingness to tolerate complicated setup to have better control over the orchestrator lead CaaS projects to Kubernetes.

And here we are: Kubernetes is an orchestrator for containers. This tool essentially lets you ignore how and where your apps run when you just want some number of them to work reliably.

The default features you get:

+ Failover (K8s makes a miracle of resurrection if something suddenly falls down);

+ High availability (N app’s copies are distributed among the nodes of the cluster);

+ Scalability/autoscaling (it can change the number of app copies depending on the load. E.g. you don’t have much traffic at night, so the cluster is pretty tiny. But it grows in size when you receive thousands of requests per minute).

You may hear that Kubernetes is quite a complex technology. We would rather call it “complicated” or excessive at times. Running the containers in k8s isn’t exactly trivial, and the entry-level is certainly higher than that of plain Docker, but it pays off with the flexibility you get.

Today is the rare occasion when we can reveal one of the secrets of Corewide’s first-class expertise in Kubernetes. Ready? Well, it’s years of experience and a clear understanding of when k8s is NOT needed.

As in any *aaS case, it’s crucial to understand whether it’s worth the effort of maintenance and adaptation, how flexible this setup is in the long run, and how the decision will affect the architecture.

GitOps + CI/CD

Having figured out where to host/deploy your app, it’s high time to develop it. Infrastructure often faces problems when keeping pace with intensive software development. That’s when fabulous CI comes to the stage to show DevOps in all its glory. A pipeline in a repository gets triggered on the new code uploaded to Git. It tests the code itself, builds it and sends the build to a test environment. The happy dev, meanwhile, saves time and sells for writing the next feature.

The ‘hands-free’ CI approach is complemented by CD. From the test environment, the checked and approved code gets merged into a stable branch and then automatically goes to production. In case it fails, everything rolls back.

How to implement the attractive CI/CD? Good news: as you wish. At Corewide, we usually suggest the one that goes together with the client’s SCM: GitHub Actions for GitHub or Gitlab CI for GitLab.

Cloud-agnostic solutions like Drone CI or Semaphore get integrated amazingly, working with any Git platform. Aim at whichever solution you find compatible with features your team benefits from.

Just a thing to note: CI/CD doesn’t prevent a user from making manual changes to a target environment but can override them as soon as it’s triggered.

Another essential concept to highlight is GitOps as the next step in automation evolution in DevOps. GitOps is about storing and changing infra state or app configurations exclusively in Git.

How does it work? Pretty much like CI/CD. A perfectly executed GitOps provides another benefit: it rolls back any changes made directly on the platform or target server. The repository becomes a single entry point and source of truth for the state of env. However, GitOps isn’t brilliant at feedback — it doesn’t clearly report the status of the changes.

Corewide’s approach is simple yet beautiful — we combine CI/CD with GitOps. Based on experience, this is the only way to handle the flaws of each process.

Monitoring + SRE

Going to production is not a happy ending — in contrast, this story is just about to begin. Having developed and deployed your app, start watching your systems’ health and stability.

The ideal monitoring system answers what’s broken and why at any time. These essential metrics will help you understand that:

• Hosting (Processes, CPU, RAM, Disk Space, I/O)
• App (Resource usage, Error/Success rates, Errors codes, Response performance, Failures/Restarts)
• Network (Established/Broken connections rate, Traffic, Network cards, Certificates)
• Server Pool (Resource usage, Scaling adjustment)
• External Dependency (Service status/availability, Operational costs)

With a fine-tuned monitoring dashboard, you can see a clear connection between how often a feature in your app is used and the processing power of the cluster it runs on. And it’s undoubtedly a game changer.

Corewide’s engineers have worked with numerous monitoring systems, from old-but-gold Nagios and its forks to everyone’s favourites (in this century, at least) Prometheus Group and Telegraf.

SRE is priceless for creating scalable and robust systems and managing massive infrastructure through code. A trained SRE engineer makes excellent use of alerting tools to set up conditions and thresholds. There’s no benefit in all that data if you can’t be notified once something goes south — but receiving a notification must always mean the issue gets fixed. Systems setup is guided by DevOps, while their maintenance always falls under SRE responsibility.

Wrapping Up

Good DevOps is all about the intelligent approach when we can determine the situation where some approach is practical and where it is better to look for alternatives. And Corewide always stands for good DevOps, so don’t hesitate and turn to Corewide for consulting.

Bonus for the most persistent:

those who have read up to this point — Cloud Migration Checklist.

Well, it’s been a long yet pleasant journey. From now on, startups can wisely escape so many failures from the first day — and it’s a pure delight for our team to contribute to your success. All we have left to say is

Dream Big, Work Smart, and Implement DevOps with Corewide!

If this post was helpful, please click the clap 👏 button below a few times to show your support for the author 👇

🚀Developers: Learn and grow by keeping up with what matters, JOIN FAUN.

DevOps for Business Growth. Corewide edition was originally published in FAUN Publication on Medium, where people are continuing the conversation by highlighting and responding to this story.