There are a lot of people a bit lost as to what DevOps actually is. Luckily, there is a great page from Amazon explaining what DevOps is. Because the approach is really basic, the discussion on what you should do to be DevOps has gone all over the place. Some people even try to quantify it with research which is pretty nerdy: concrete examples of what it means to be DevOps rely heavily on the situation. There is no specific technical approach for a general philosophy like DevOps.
Lets first start with what DevOps is: making sure the right idea gets to market, as quickly as possible.
The biggest hurdle used to be handover between development and operations. This is often no longer the case: as most companies are on cloud based services, ops is often a cloud provider. And cloud providers want to scale their customer base and therefore minimize customer interactions and/or delays. We are now left with a general approach where merging Dev and Ops is no longer the focal point of implementing DevOps best practices.
If we accept that, we are left with a few point that are still really interesting and also give us some concrete steps to take. Let’s dissect my definition of DevOps: making sure the right idea gets to market, as quickly as possible.
- making sure: this means certainty in development, deployment, and clarity in feature design.
- the right idea: once a feature is delivered to the customer, we must make sure it has the intended result. This means that all features must have decisive monitoring approach allowing for the feature to be evaluated. Here, decisive emphasizes: if the feature is not performing correctly, it should be removed.
- to market: a feature is done if customers are using it and business is monitoring it (full feedback loop).
- as quickly as possible: never loose sight of quality but also make sure you deliver before the competition does. A balancing act that is has given rise to automated testing and functional programming.
As you can see, these are general things not to be confused with specific statements like you should have CI/CD set up. If you have a WordPress site where your company publishes news articles, you are not going to make your company more DevOps by removing WordPress and changing it to a static site generator with a CI/CD pipeline. You will make it less DevOps because you are changing the sub-second publish and update of the news article possible through WordPress, into multiple-minutes pipeline build of a static site.
Ok, so if not tools, what then? Well if you want to solve a problem, the best thing to start with is making the problem clear. Here are some steps you can take:
Define to market as the full circle: a feature is available to customers and the business is informed about the performance of this feature. Make the feedback loop as large as possible, after that worry about how long it takes and optimize.
Measure your time to market as the time between the development team picking up the feature and the customer response analysis is seen by the business. You can measure all steps in between to see what you can do to optimize the complete flow, but that should be considered an optimization. If you are using a ticketing system, you can probably already measure this as: the time between the first backlog item of a feature being picked up and the feature finally closing after being evaluated by the business.
A feature must include a measurable goal. This seems simple, but defining how you want to measure the success of an idea can often be difficult and should not be taken lightly. Everybody can be enthusiastic about ideas, it’s harder to talk lightly about when you have to kill and idea. One way to force this is to require the feature to include actions based on monitoring results, for example, if user engagement is less then X we should drop the feature.
Of course just doing three things, won’t have you picking the right tools for each improvement. However, implementing these three steps should get you closer to exposing the problem that DevOps tries to solve.