Why External DevOps company is better

by (March 14, 2017)

Posted in DevOps  Tags:Management


Following information is valid if your organisation:

  • under 100 people;
  • needs cost effective solution for DevOps.

If there are more then a hundred people in your organisation, then you probably can afford to replicate our recommended DevOps team setup to contain:

Block Diagram

  • DevOps architect - someone who can match your organisation needs against the common practices and negotiate required architecture changes of product you are developing with development team[s];

  • DevOps senior - someone who knows systems and their administration well and is able to produce a good implementation plan, implement core parts and explain implementation details to other members in the team. Quite often Architect and Senior are the same person, but for larger organisation Architect does more of business analysis where Senior os more occpied with teams and tasks management;

  • DevOps middle - this guy will actually do the rest of implementation and keep the whole solution cost effective.

  • DevOps junior - helps middle with simple tasks. Typical organisation could work without juniors, but then it should spend resourses on hiring middle engeneers. Junior level is a bench where talented people could learn all the required skills needed for successfull work as a middle, sometimes people coming here already know at least SysOps or Software Development;

Good DevOps Job: definition

What should best DevOps [team] do? In our vision, the following:

  1. Gather the requirements within organisation
  2. Match those requirements against current best practicies
  3. Negotiate architecture changes, if required with development team
  4. Implement the solution
  5. Consistently maintain it along the time.

… and do the all of the above promptly and cost-effective way

What most organisation do

To prove the topic of this blog post, lets analyze typical approaches.

What companies are usually doing is one of two possible alternatives:

  • They hire DevOps engeneer.
  • … or they try to convience/convience some of developers to do the DevOps jobs.

Does this work? Yes. Somehow it does. Is it cost effective? In most of cases: not, (if you compare any of approaches above to the DevOps As a Service). Is it reliable? Neither.

Yes, for someone within your organisation it is much easier to gather the requirements. But then:

  • If in-house DevOps experience is high (Middle/Senior),
    • (+) then he or she will make high quality architecture and implementation
    • (-) coding everything using high skills engeneers time is a waste of resources;
    • (-) After the main projects are finished (and they tend to finish in a few months when there are several products) higly experienced DevOps engeneer will be tired/bored by doing some maintenance, and so starts looking for new job;
  • If you hire /Junior/[ DevOps, the solution quality could suffer due to some incompletions, and so the total cost of it will grow up. Even in such case, when the implementation is finished, there is not a lot of work for this person until you code a new product or service.

DevOps as a Service team setup

Block Diagram

  • To make it cost effective, in bigger DevOps team the responsibilities of people are devided by project stages and levels of experience, thus making the whole implementation both cost effective, reliable and following the best market practices;

  • DevOps Senior/Architect in role of Business Analyst collects the requirements from development team;

  • DevOps system architect provides and negotiates with developers the best architecture for your application or service. It might be possible that some changes will be required in the product itself to make it perform the best.

  • DevOps Senior:

    • implements the most complex parts of work;
    • works in pair with Middle and Junior developers to help the to do the rest;


So, as it has been explained in Good DevOps Job every project or service automation is going through the same flow:

Block Diagram

Stages 1-3 are so-called “active development” phase, stage 4 usually requires much less efforts, when 1-3 are properly done.

Compare the approaches

Advantages of in-house DevOps

Security considerations

This is quite important for most of the companies, and for some it is the whole deal stopper, especially if you are working with regulated data, like military or certain types of government agencies. So, in such cases, there is no other choice but to run DevOps in-house.

General security considerations apply for typical business as well as the data which DevOps touches is a heart of your organisation. You might (and should) worry about giving access to company data to some external company, and the problem here is that usually you can not avoid that. So, careful analisys of your perspective DevOps company partner should be made before you actually sign the contract.

For our clients we usually refer to some other clients and let them speak directly to understand the past experience and obtain some feedback. Looking at company ranks on public resources is also highly adviced.

Signing required NDAs, obfuscating data and other things - those are all valid measures against possible data leaks, which we usually help to implement.

What if contractor disappears?

This is also valid reason and we often hear this fears from the potential customers, especially when people discuss it among themself. While this could be a valid reason, I almost never heard of situation, when potential contractor obtains the contract and then suddenly disappears - as a minimum he won’t be paid, and of course this might ruin his reputation. So, in real life those examples are rare, but of course, check the reputation and obtain a few referrals before you start working with someone, would it be DevOps or any other contractor.

Disadvantages of hiring in-house DevOps

  • If you hire Senior, it would not be cost effective on all stages. While Senior will be appropriate to put all requirements together, using Senior for all implementation stages, deployment and support will cost you more vs. the approach when less critical stages are handled by less experienced members of the team;

  • If you hire Middle, he would do the good job, in average. But if your project is complex, he might lack some of experience, thus making your project either span longer time or contain some wrong architectural solutions, which would leak again to more expensive result;

  • If you hire Junior, or ask some developer to do the DevOps automation, it can result with some ineffective architecture, especially on first stages of developmnt. And when architecture is bad early, expect larger impacts on the project lifetime. And so: Not recommended. Even if you use brilliant software developer, with great sight of architecture, he may put up great system in result, but it will probably lack of common industry practices.

  • Certainly, DevOps usually means that everything is automated and nothing will break. But in real life, around 10-30% of all DevOps work is still related to typical SysAdmin tasks:

    • systems monitoring;

    • problems detection and resolution;

    And this imply availability. And so, it raises questions about vacations, ill days and other reachability problems.

Advantages of DevOps as a Service approach (DaaS)

  • Team, which has an experience of automation of Nth companies can give you very good advices;

  • Such a company can provide wide range of expertize, which can be applied in correct stages of development, lowering the total cost of ownership;

  • Someone who already has experience building scalable deployments and automating all daily development tasks can boost the speed of changes within your organisation and make it possible in short time to refresh most of the procedures using new-generation approaches popular nowadays.

  • Most of DevOps as a service companies are very reliable, as it is their core job and main interest to provide high quality support to their customers. You won’t worry that your DevOps is on vacation or leaving - as all those issues are handled within the contractor;

Lets talk some numbers

To illustrate the above pros/cons lets try to calculate project budgets.

Assume that:

  • DevOps Middle labor cost: 0.5 * Senior
  • DevOps Junior labor cost: 0.1 * Senior

Automation of development pipeline of 30k < typical project < 100k lines of code usually takes around:

Project stage Senior, hrs Middle, hrs Junior, hrs Cost
Plan 120 30 0 135 (120+30/2)
Code 60 200 40 164 (60+200*0.5+40*0.1)
Deploy 20 50 10 46 (20+50/2+10*0.1)
Monitor & support (per month) 10 10 50 20 (10+10/2+50*0.1)

This is the most balanced setup. Here we have:

  • The most important part of work is done by most qualified persons for this job;
  • The work is done faster because on many stages people can work in parallel;
  • Support costs are low;
  • The price of this high quality work is lowers among the other 2 variations.

Same project done by Senior

Project stage Senior, hrs Middle, hrs Junior, hrs Cost
Plan 140 0 0 140
Code 190 0 0 190
Deploy 75 0 0 75
Monitor 40 0 0 40
  • The calculation here must be more/less realistic, as Senior anyway will work faster then Middle or Junior, so not all hours are summed up;
  • The total time for this project will be bigger, as the single person has to do a lot of different work;
  • The total price is bigger as the Senior work is the most expensive. Also, please note that as soon as project is finished, the monitoring and support work could be too boring for Senior.

Same project done by Middle

Project stage Senior, hrs Middle, hrs Junior, hrs Cost
Plan 0 450 0 140
Code 0 300 0 190
Deploy 0 120 0 75
Monitor 0 30 0 40
  • This solution has one big disadvantage: Middle might not know all the things well, as result the architecture might be not so optimal;
  • The implementation will be slower then previous two;
  • The cost is still bigger then most balanced solution.

Yes, by the cost the solution created by Middle would cost less then done by Senior. But here could be a problem with Architecture, it could be possible that final solution is not the most effective.

What about solutions created by Junior from beginning the toe end - it makes no sense discussing it, as usually those are not typically usable in long time period and subject to rewrite due to bugs in architecture and implementation.


Using DevOps as a service is an effective solution by the following criteria:

  • Total cost of ownership;
  • Implementation time;

Using experienced team in the field is always a good choice. Your organisation should try it.

Let us know!

Contact details:


Services you are interested in: