DevOps for startups

A big change happened in the world of software development with DevOps emergence in 2008. It became a fundamental shift of focus in сompanys' culture, organizational principles, and approach to development and operations. With having DevOps adopted, companies broke the 'us and them' mentality and built close cooperation between teams.

Numerous companies established at least two decades ago passed their way through the chaos, waterfall development, and agile principles and today 80% of them try to implement DevOps best practices. For startups, the situation looks winning because they can implement it from the early beginning and avoid the mistakes made by someone else.

So let's uncover how DevOps can be helpful for startups wishing to become unicorns!

Modern tech stack allows startups to enjoy the benefits mentioned above, but the proper its set up and utilization is a must. Otherwise, you will lose time and can be caught by the technical debt (we will discuss it later). So let's consider what you need to make the DevOps adoption for your further success.

Public cloud providers like AWS, GCP, Azure offer a wide range of services helping to build a robust infrastructure in the cloud. That's why companies that adopt cloud computing right away have the opportunity to use all perks like HPC, microservices, serverless computing, ci/cd - everything that DevOps best practices require for building a well-architected infrastructure.

You can refer to the AWS guide, where they provide a detailed description of the concept of the well-architected framework. This concept allows developers to create a reliable, secure and highly efficient infrastructure for your software/application. Briefly, this concept includes the optimization strategy of 5 main points to achieve excellence:

• business process 

It concerns automation, daily operations management, and disaster recovery scenarios. Without having properly business processes established, there is a big chance to stumble over the pitfalls of poorly developed infrastructure even if you have a team of top-notch developers. The reason for this is poor communication and the absence of tactics plan in case if something goes wrong. So the task #1 is to optimize the business processes.

• security 

this principle focuses on data security and confidentiality, user's role management, and indication. Security is the most important thing to consider when developing architecture from scratch.

• sustainability 

This concept helps prevent failures and, if any, swiftly recover from a disaster. If you follow the advice, you get 99% service availability and happy customers.

• high performance 

this framework provides tips on how to use your IT resources wisely. It concerns mostly the issues of how to choose the right tech stack, calculate workload, monitor the efficiency, and making data-driven decisions.

• cost of the infrastructure maintenance

The most important part for a newly established company. Learn how to analyze your spendings over time and how to plan a budget.

Well architected is not only an approach to development, it's also about business processes optimization. That's why you need a team lead or CTO. It is critically important to have a professional with corresponding experience and knowledge, who will understand the platform and take over the responsibility for decissions on its tech stack and communication with stakeholders (or business executives).

DevOps workflow is all about managing and optimizing. And infrastructure is one of the key aspects. Infrastructure automation (also known as infrastructure as code, or just IaC) eliminates the ever arising problems like "it works on my machine" or "oops I did it again".

It may be quite difficult to automate everything in the beginning, especially it may be hard to keep up with high pace of changes in startup, but at least you need to try applying the IaC principles in your infrastructure, so eventually when the application and architecture are more or less stable you can get rid of human-caused errors, which can influence the availability of your service.

Why do we need them at all ? Having a team of developers working together on same repositories requires proper setup of dev and test environments to avoid situations "it works on my PC, it's not my problem anymore". Hopefully Docker can be used to make sure that all developers use the same environment configuration. So if the application works with a new feature on the dev machine, it has much higher chances to work also in another environments.

You've probably heard about docker orchestration tools, and the most hyped one is the Kubernetes. Using tools like Kubernetes can slow down development process, especially if developers don't have enough experience with it. But if you already decided to use it (when configured properly) with tools like Skaffold can bring the development speed to another level.

It all depends on the stack you've chosen for your application. When we are talking about early phases of startups - log management and ability to get quick feedback on issues happening in the application is crucial to help developers find the root causes quickly. If we have a setup in GCP or AWS there are natively supported log management services with centralized access to the application logs.

When we are talking about debugging the application or getting notified about exceptions - you may consider such tools like Rookout andSentry correspondingly. With this set of instruments or their analogs, the team developing your application/platform will have quite good level of visibility on what is happening with the application.

Monitoring of resources is not that critical at the early stages, but it progresses more with the `ready-to-production` deadline and helps startupers make data-driven decisions.

When we are talking about good code we mean some best practices, company principles, programming language standards that we need to comply with. Try to get the team around your Tech lead that knows why it's important to use git branches and pull requests, instead of pushing into master "because it's faster". Why git matters in CI ? Because it's the root cause of the problems you may have when setting up proper CI ( and not even CD yet ). When the git workflow is defined well, when all (or at least most of the) team uses it properly, it is very easy to setup good CI flow. Until you get to the tests…

Let's be honest - nobody does tests until it's too late. Startups need to deliver fast, developers write code and we rely on developers submitting ready features into environments. CI doesn't need to have tons of tests, so at least you can try to start from small parts (linters, basic unit tests). Having some CI process is better than not having it at all.

What about CD ? For sure it's good to have it in place, but most likely there is no much automated tests in your application and most of the tests are done manually by QA engineer. If you don't have any - it's 95% that your Product/Project manager is doing all of the tests in non-working time. To have some progress in CD setup try to plan how you can move the testing flow in backward direction.

As we mentioned above, it is not enough just to implement the technologies. It is important to implement them properly from the first effort.
The most widespread problem of a startup is the speed… they have to work very quickly and deploy as much as possible to keep the investors and clients satisfied. Meanwhile, the developers may not keep up with the tempo or have not enough expertise in the required technologies, thus, they do as they can, not as it is required. That's one of the TOP technical reasons why 8 out of 10 new businesses fail*.

So what is technical debt?
Technical debt is a final cost of the additional reworks and refactoring caused by choosing the wrong / the easiest solution in haste rather than using best practices.

TOP reasons:
Experience has shown that startups usually meet the following challenges:

1. Pressure on the business from the side of investors / impatient customers.
2. Lack of experience in team management and weak understanding of the consequences.
3. Creating of the inflexible monolithic systems.
4. Poor quality of the code.
5. No time for tests.
6. Absence of the documentation.
7. Miscommunication between teams.
8. Team members don't fully understand the business goals and start taking too much responsibility for decision making, which results in shift of the focus.

The biggest problem of the technical debt is that it has an accumulating effect. The more time you keep the existing infrastructure without refactoring, the more you get bogged down.

How can a startup avoid technical debt?
However, you can't avoid completely a technical debt as it is. Trends are changing too fast to keep up with them. Today's modern architecture may occur obsolete in a few years. But you still can reduce the risks.
So, if you are limited in time, you should select a top-notch team with solid experience, which team members not only have hard skills in DevOps, but understand business from the bottom side and know how to build the communication within a team. Surely, it is more costly choice.
If you are limited in budget, your time is your treasure. Plan in advance each project stage with a detailed description and follow it step by step. The most important here is to have a leader responsible for decision making and communication within a team.
Above all, a skilled and experienced CTO is a MUST for both cases, since a good CTO would make sure that the team is designing a stable application, test it properly and scale in accordance with customer feedback and needs.

Let's make a short synopsis of the statements above on DevOps for startups

• Your startup would 100% need to consider: well-architected infrastructure in the cloud, infrastructure automation, continuous integration and deployment (CI/CD), containerization, log management and monitoring. These are only halfway towards a DevOps culture within your startup.
• It is important not just to use the hyped technologies, it is important to set up and leverage them properly.
• Communication between teams is the second half of the success.
• Never forget about technical debt and its cunning consequences. Haste and effort to save money on critical issues can turn out one day as a big challenge impossible to eliminate.
• Any startup requires a good CTO with appropriate skills and previous experience. This CTO is responsible for final decision making and team-leading. 

Questions? Contact us for a free consultation on DevOps implementation for your startup!