- SG: +65 64383504
- IN: 022 25771219
- IN: 022 25792714
- IN: +91 9987536436
DevOps – To get it right, get to know what it is not!
Sameer Kumar I Senior Solution Architect, Ashnik
Recently, I have been spending a substantial amount of time working with folks from operations in various enterprises. Most of the times, their stories are very alike – the Ops teams are having trouble with the way DevOps is being ‘adopted’ in their respective organizations. DevOps is no more just a buzz word, it has quite become the cornerstone of many Digital Transformation processes. Yet, there seems to be a lot of confusion about what DevOps is and how one should go about it. Let me try to elaborate on some of the aspects which people get wrong in their DevOps adoptions.
First of all, it is a not a management process to be cascaded to all sys admins and developers. It is not a policy or strategy that is an outcome of a research/management paper published to increase effectiveness or productivity. It is rather a new culture, it’s a mindset. A paradigm shift is happening to respond to problems which started cropping up once rapid development and deployment (read as ‘Agile’ and ‘Digital Transformation’) became need of the hour. So before you start adopting DevOps practices, you would really need to understand the problems it tries to solve and the cultural shift it demands.
Secondly, it is also not about a hiring a new role or a DevOps engineer for being part of your team. Seriously, it is not. Adopting DevOps does not mean that you will need new engineers who can develop and also perform system admin tasks. Of course, your team will start picking up new skills as they go along and as the lines between Development and Operations blur a little bit. More than skills and adding new roles, it is a change in the thought process itself. Instead of defining accountability of developers as “makers” and sysadmins as “doers” or “checkers”, now development, deployment and operations are shared responsibility. You might see your sysadmin writing a bash or python script to ease some development/deployment pain e.g. provisioning a facility to migrate SQL structures easily from dev to production environment or a facility to replicate environment with click of a button or a command. At the same time, you would see some of your development teams taking ownership of a setup and life cycle of an environment e.g. using the facilities provided by sysadmins to create a new test environment as a copy of production environment. The core skills and responsibilities of your team would not change, though there will be definite changes in things they are accountable for.
Finally, I have seen many people in leadership positions tagging DevOps with a specific language e.g. Python, Perl etc or with specific technologies e.g. Docker, Cloud, noSQL databases, Ansible to name a few. While this dilutes the core value-add that each of these technologies carry, such notion also ends up pushing for an aggressive makeover of your whole IT landscape. Of course, these tools gel well with DevOps philosophy. Given that these tools have been developed around the time when DevOps ‘culture’ was picking up, they should be already factoring that paradigm shift. But that is all. Even before you push these tools down in your IT build farms, you need to first absorb the essence of DevOps. Otherwise you might end up adopting these tools (which might have its own benefits) but not benefiting from them in your DevOps adoption. Nothing stops your DBA from automating a deployment in bash script instead of Ansible – though that could be complex and without reusable components. That is how you should look at these tools – they make your DevOps adoption easier but adopting these tools is not same as adopting DevOps.
I’d like to conclude by adding that if you want to adopt a DevOps culture, you can’t reduce it to just management policies, new roles on job portals or adoption of a select few tools. To turn it into a reality within your organization and reap its benefits, you need to embrace the new thought processes and foster a DevOps culture. At Ashnik, we work with some of our key customers in their journey of Digital Transformation. In these journeys quite often, we work with various project teams to imbibe the DevOps into their IT culture. If you are also embarking upon DevOps or have already started the adoption by means of new policies, roles and tools, feel free to get in touch with us and we can discuss how Ashnik can help you on your new voyage.
Sameer Kumar – Senior Solution Architect, Ashnik
Sameer Kumar is Database Solution Architect working with Ashnik. He has worked on many complex setups and migration assignments for some of the key customers from Retail, BFSI and Telecom Sector. Sameer is a certified PostgreSQL and EDB Postgres Plus Advanced Server Professional. He is also a certified Postgres Trainer and has delivered many trainings for public and corporate batches. He is well versed with other RDBMS e.g. DB2, Oracle and SQL Server and is also trained on noSQL technologies viz MongoDB. He has worked closely with customer and helped them build analytics platform on noSQL databases and migrate from RDBMS to MongoDB. And while he’s in the free mode, he loves to take his cycle around Singapore for a spin.
- Would PostgreSQL leak your data? No! But YOU might!
- Integrating Docker Trusted Registry with Google Chat
- Chaos Engineering with Docker EE