From startup to enterprise or within a startup incubator inside an enterprise all want to focus on innovation and get the latest on automation and quick releases, there is a market demand for talent and a huge GAP to be filled.
CIOs CTOs COOs Head of… all are now expected to be Entrepreneurs and proactive, many of my conversations I have with my clients is about the new trends in IT and the pressures to be up to date and to speed on delivery.
But if Cloud is new, DevOps 2x newer which means talent is scarce and whenever you see such a huge GAP of knowledge and hands on in the market naturally consulting will spike although everyone struggles to get the talent with 4 years of hands-on experience.
You can use the external DevOps help temporarily only, your organisation has to OWN the process from top to bottom and for some organisations the philosophy change is so radical that the adoption process will take the longer curve it’s just to outside their bubble and the innovators will be seen as fanatics or cult evangelists.
Trending tools can accelerate automation and make the release cycle more agile and it’s here automation and DevOps are thrown into a grey area.
DevOps-as-a-Service = automation, the service provider will have to opt for a set of tools and uniform the offering to its clients, it will be paired with the in-house knowledge of all it’s support teams, this can lead to different teams with different skills and the pace they have to learn vs speed of implementing and shifting challenging to sustain.
This approach is great if In-house operations and dev are separate, one sees the infrastructure others sees code only.
Silos and conflicts rise because both of them are not proficient or resist to be it dev or ops, egos are in play and many times the finger pointing is the norm because they don’t communicate or trust each other work and competencies internally, I have seen this over and over especially on parallel hierarchies.
Having a 3rd party will enable you to bridge the skills necessary to implement automation and refocus your staff into your applications and processes.
When you have to scale your environment to match demand or simplify stack deployment and eliminate the “snowflake” effect DevOps-as-a-service is a middle step to a maybe DevOps bright future.
Now the more you have the more you want, once you start seeing the possibilities and advantages you start to adopt an experimentation mindset, you want to use the automation more and your initial project grows which means you demand more value from your Service Provider.
This drives you to put more and more demands on the service provider and consuming more time and investment from your service agreement.
Well, your service provider on the other hand on the long term will struggle to keep you happy because they have to move slower than you, they are looking for uniformization and a stack that fits all.
The service provider will realise you are not profitable anymore (hours vs monthly fee) and/or you decide he’s too limited, one of you will break apart as a kid becomes an adult and wants to explore the world by himself and create his own vision.
DevOps means also the freedom to use any technology or tools available, it means experiment and pivot frequently, you don’t know the end result or the path, you have VISION and “make it up as you go” towards that vision.
The Professional Services approach, on the other hand, requires a much deeper organisation buy-in both vertically and horizontally.
The consultants should also become part of the team (temporarily) and their goal is to be your knowledge library and transfer the information to you, the client.
It’s a project were typically the costs will go up before going down, the change is always for the long term (VISION) and the savings can be demonstrated, traditionally a workshop and discovery must happen prior to determining where you are now and what needs to be done to get you to your VISION.
Empowering the client means Developers and Operations internally don’t exist any more and you group them in smaller teams (split a pizza), the end goal is for them to become mature enough to release to production directly through trial and error instant feedback through split testing APM and realtime data analytics.
With this approach once the project is “done” (from the consulting part) you are left alone to continue your journey, professional services can come back but always as outsiders, you own the full cycle of your applications architecture and services, this is non-negotiable and if they do boy you have bigger problems.
The change really happens here, you are now innovating by encouraging knowledge sharing and you can’t tell who develops from who manages, everyone does, split testing, smaller quicker deployments directly into production and when your SOA and micro services architecture reaches maturity welcome containers and kubernetes etc, all is well in paradise and unicorns also fly.
Depending on the stage you are at you cannot expect your internal knowledge to cope with the shift and complexity of today’s trends which are allowing organisations to continue to grow to innovate pivot and face the aggressively competitive and changing IT landscape, today and more than ever before IT is what is allowing businesses to strive.
Depending where you are at and your goals both options are valid, doing nothing will be too late.
Disclaimer: The opinions and ideas expressed in this article are those of the author, and they do not reflect in any way those of the institutions to which he is affiliated directly or indirectly.
