Our DevOps as a Service offering in the DevOps Team Topologies paradigm
DevOps Team Topologies — created by well-known experts in the field — classify, compare, and contrast effective and ineffective team models as well as DevOps practices for modern software delivery.
It describes DevOps anti-types and DevOps team topologies opposed to them. The latter start from Dev and Ops Collaboration (Type 1) and go through other options till Dev and DBA Collaboration (Type 9). These types vary in how they work, when they can be applied, and their potential effectiveness.
According to this classification, the model we implement is formally called DevOps-as-an-External-Service (Type 4).
DevOps as an External Service as a basis
“For smaller teams or organizations with limited experience of operational issues.”
“What might be called DevOps-as-a-Service could be a useful and pragmatic way for a small organization or team to learn about automation, monitoring, and configuration management.”
(from DevOps Topologies, Type 4)
Palark is generally perceived as an outsourced DevOps team (and for good reason). That’s what we basically do: providing DevOps & SRE as a ready-to-use service for our clients’ needs. However, the way we operate and the benefits we provide are more than just DevOps as an External-Service as it’s described in DevOps Topologies.
Years of experience working with clients of all sizes allowed us to cover a much broader range of business needs as a part of our DaaS (DevOps as a Service). That’s why we prefer to say we follow a hybrid DevOps/SRE model that extends formal Type 4.
Our hybrid model
Providing DaaS, we help our clients with various tasks revolving around application architecture and containerization, building CI/CD processes, operating Kubernetes, and databases… Even companies with full-time Ops and DevOps teams don’t always have the resources to cover all those areas. When it comes to smaller companies, this is even more so the case.
Another important point is our strategic stance with regard to cooperation. First and foremost, we aim to achieve the desired business outcome and long-term collaboration rather than earning an hourly rate. This renders our approach very close to that of an in-house team that just happens to work remotely.
If you keep this in mind while looking at DevOps Topologies, you will see that we apply principles embedded in some other topologies along with the DevOps-as-an-External-Service.
Ops as Infrastructure-as-a-Service
“For organizations with several different products and services, with a traditional Ops department, or whose applications run entirely in the public cloud.”
“The internal Ops team is thus directly equivalent to Amazon EC2, or Infrastructure-as-a-Service… This team is still a Dev team, however, following standard practices like TDD, CI, iterative development, coaching, etc.”
(from DevOps Topologies, Type 3)
We manage the infrastructure by following the Ops as Infrastructure-as-a-Service model: we design, build, and maintain all the things you need to run your applications on (as well as interact with vendors). We believe creating and maintaining infrastructure is not a core competency but a commodity even for clients with a technical background who develop their own software products.
To further explain this, we can use utilities as an analogy: an apartment owner buys water, electricity, heating, and other ready-made services from a third-party utility company since it makes no sense to generate and maintain it all yourself. The same can be said regarding the platform on which the customer runs their applications. The top priority for the business is implementing the features of the application that are in high demand among users and generate revenue.
At the same time, it is important to emphasize that we do not limit our customers in their infrastructure choices. The platform we are developing supports various public cloud providers, private clouds, and bare metal.
“Containers remove the need for some kinds of collaboration between Dev and Ops by encapsulating the deployment and runtime requirements of an app into a container. In this way, the container acts as a boundary on the responsibilities of both Dev and Ops.”
(from DevOps Topologies, Type 8)
All of our customers either use Kubernetes, or we are currently integrating it into their workflow. But you have to containerize an application in order to (efficiently) run it in such an environment. Fortunately, there are best practices — mostly related to SRE (Site Reliability Engineering) — to make this possible and fruitful. We share them with our customers and encourage them to adopt them.
Containers become the basic building blocks that we get from the Dev team and run them on the infrastructure. Meanwhile, Kubernetes becomes the communication language between Dev and Ops.
And even more
The Type 6, DevOps Advocacy Team, is another integral part of DevOps as a Service from Palark. We actively advocate industry best practices for the benefit of our clients, striving to help them achieve their business goals. Having been in the market for so many years and participated in so many projects of different scales, fields, and underlying tech stacks, we have accumulated experience and automated it in our own Open Source solutions, configurations, and processes.
We strive to bring the quintessence of this experience by delivering it both verbally (via communication with the Dev team) and practically (via the technical solutions we apply).
The Type 7’s SRE Team (or Google Model) is also a part of our DaaS. Our engineers handle SRE-related tasks by helping to fix code problems that affect application availability, performance, and other business-critical metrics.
We coordinate these metrics with business representatives and then track them with powerful observability tools. We report the detected problems to the client’s Dev team. Together we troubleshoot these issues, whether they are related to the application architecture/code or the infrastructure solutions used.
At Palark, we treat DevOps as a Service not just as an ordinary offering of DevOps Type 4 topology but as a comprehensive hybrid DevOps + SRE model. It integrates several formal topologies and is based on the following principles:
- Provide infrastructure as a service tailored to real customer needs.
- Focus on key business objectives and long-term cooperation.
- Work closely with the client’s Dev team; promote the industry best practices and foster their implementation.
Such an approach makes implementing the ideas inherent in the Dev and Ops Collaboration (Type 1) model possible – to the best of our abilities as an external team.
“This is the ‘promised land’ of DevOps: smooth collaboration between Dev teams and Ops teams, each specializing where needed, but also sharing where needed. There are likely many separate Dev teams, each working on a separate or semi-separate product stack.”
(from DevOps Topologies, Type 1)
Pursuing this promised land is our focus in rendering DaaS service. We incorporate and continually review all the lessons we’ve learned as well as the experience, best practices, processes, and technical tools we’ve accumulated.
We have been working with Palark for the last six months. Their DevOps team was really involved in the project we delegated to them from the very beginning. We came to Palark after seeing one of David Magton’s [their CTO] talks. At that moment, we realized it was the partner of our choice. They have a vast experience, a well-coordinated team, their own versatile set of tools to implement convenient and efficient software delivery and manage all the machinery under the hood of our apps.