Actifio is now part of Google Cloud. Read the full announcement.

Development Operations Advice from a Thought Leader

Development Operations Advice

Giovanni:  Hi everyone! This is Giovanni Tropeano, Director of Digital Marketing with Actifio and I want to thank you for joining us in this week’s blog post.  We are  joined by Ashish Nanotkar and John Annarelli of Yash Solutions.  Ashish is the CTO of Yash and John is the Managing Director and I also have with us Jay Livens, Senior Director of Product Marketing here at Actifio.  Today we are going to be talking about DevOps in general, so Jay why don’t you take it away?



Jay:  Thanks so much Gio and thanks so much Ashish and John for joining us.  Well I thought it would be helpful if, before we get started, maybe if you could give us two seconds on your background, who you are, who is [0:01:00] Yash Solutions, what do you guys do because not everyone listening might be familiar with your business.


John:  Sure so this John Annarelli, managing director at Yash Solutions, Yash Solutions has been in business 17 years and over that time we have serviced enterprise clients all around the country and based out of Atlanta Georgia and what we do is get into a lot of operational initiatives for say the first 10 years of our existence, but over the last seven years or so we’ve really been involved in a lot of application related projects.  So since we’ve been working with Actifio over the last probably four years or so, we’ve really gotten into a lot of areas in application development or [Inaudible] [0:01:51] virtualization.  So while that has taken off for us, is we have had some pretty good size winds in that space [0:02:00] what we’ve done in the last two years or so is really tried to tie everything together especially as the industry is going towards DevOps and working to offer our clients bundled solutions, so time and technology, multiple things in the environment and then some additional automation which Ashish here is going to talk about, that has really been something that we have been developing internally for about the last year or so.  And I will turn it over to Ashish to talk about some of the technical aspects of that but that in a nutshell is a little bit about our background and our initiatives going around the DevOps space.


Ashish:  Thank you John, this is Ashish Nanotkar, CTO of Yash Solutions.  So with the efforts that we are doing in the DevOps space [0:03:00] , we are building a solution that is very generally pertaining to various different sections, let’s say verticals, in the DevOps space which very few people touch upon.  The target is to have a seamless experience across all the stages of DevOps, would it be along the code lines, would it be along the databases, would it be along the operation side of it or the human cultural and behavioral part of it, which everybody maybe talks about, but they pay very little attention to when it comes to implementation part.  We have been working with our clients, taking feedback, looking back on our experience and building something for the future, at the same time making it cost effective for our clients and trying to make sure that they are future ready when it comes to switching the technology or building up the skills or self sustaining the mechanisms [0:04:00] or creating systems that are self aware, self healing and spread across multiple job relocation.  So trying to understand problems at very generic level which can be then specialized in different client situations so that is what we are working on right now and a couple of things which are going to be future impacting from our perspective that we see are containerization technologies, data virtualization technology is out there, orchestration, cloud diagnostic services, hybrid clouds, hyper converged infrastructures and all that stuff.  Looking forward a couple of days from now we might be launching our own solution into the market.  So that would be great to see how clients come up with their [0:05:00] ideas, their feedback so that we build and form a larger vibrant ecosystem system around the DevOps space.


Jay:  I think DevOps is an area that we hear so much about and I am curious with you folks talking to so many companies, I am wondering what trends that you see in DevOps that you see companies asking about on a pretty consistent basis?


Ashish:  Thank you Jay for the question.  There are particular trends in the field of virtualization.  First that’s the one that has been going around for long.  The second one which is a late trend, I would say it is late because people have now started catching up on the concepts of the way DevOps works with agile and brings agility to you at the moment, that’s second understanding.  Third understanding is on the lines [0:06:00] of agnostic services rather than vendor specific services and I will talk about all of these three points in detail.  So the first one I talked of is about the DevOps space, being in lines with agile, right?  So people were talking about agile for a long time now, agile manifesto came in 2014 late 2015, they came up with the new agile manifesto which is the four point manifesto that talks only about making people awesome and that’s the whole point of it.  So when we are doing DevOps or trying to bring in agility in our companies, we always need to be on our toes to adapt, to provide environments which are allowing people to feel and feel fast at the same time catching them, not letting the problem sift through in production.  So we want the software’s to be always [0:07:00] in a deployable state right?


And we always want our people to be productive, not blocking each other.  So for that to take place in a DevOps space you need to make sure that you have the right collections of tools and people have started to understand that so how can we use technology to change or transform the way we behave culturally inside the organization?  The type of team structure that should be the distributions, the way communications happen, the hierarchy structure and all of that stuff, including the tools and processes that he said and that option rate of the tools is something that matters, that’s the first trend that I have seen in the market, that people are more aware about their culture now, they are trying to move towards the startup like economies where they can lower down the costs, make sure that each and every person on their team is accountable and takes ownership of the stuff, that is the first trend that is driving the DevOps initiatives, [0:08:00] the way it is right now, otherwise it was only confined to the market leaders of the industry right?  Then it started sipping down and it’s good that we are at the right time, at the right place to take this at a greater speed.


Another trend that I see is about the virtualization technologies so initially when people were talking about data centers or on [Inaudible] [0:08:24] setups, it was mostly about physical boxes and now they are moving to cloud and that’s the trend that everybody is talking about and when we move to cloud, we talk about APIs and Integrations and options that we have because there is a wide platform, there is a lot of choices that we can choose from right?  To choose from a particular cloud vendor or a particular service or maybe choose a platform that will allow you to spread your footprint across the globe on different cloud solutions, there are a lot of possibilities down there [0:09:00] and when people talk about that, they try to experiment with it and they come up with a new problem right?  And every problem comes up with its own solution and possibilities in that area.  So something like let’s say you are setting up things on a virtual machine and then enormously, even if you are not being a friend, your monthly bills on cloud would be enormous so they are coming up with new options and there is a blooming technology around containerization that is going on.  So virtualization is slowly moving from the VNs to its containers, from moderate architectures of applications towards micro service architectures.  Your monitoring changes the way it was before, your login sequence changes, the way applications behave internally is different.  They have various different processes, [0:10:00] communicating with each other, various different services talking to one another which defines the way your operating system should work, which defines the way your infrastructure should work and applications are getting more and more infrastructure aware these days.


So initially when people used to develop, they used to develop in a scale, they go out and then deploy on [Inaudible] [0:10:22] which caused a lot of problems and this is what we are trying to solve with DevOps.  Now today it’s good to see that applications are infrastructure aware that means they know what kind of infrastructure is going to be there, how many codes are going to be there, do I need to have multi processing or multi pairing, what kind of third particles are going to be made?  So this virtualization and self awareness in the apps is the next trend that is going to be really beneficial and will drive the DevOps to a completely new direction.  Now the pattern that I am seeing in DevOps is about [0:11:00] virtualization in the data space.  So when I talk about that, I am also going to talk about the vendor login scenarios here.  So let’s say you have a code and you want to deploy it somewhere, what people generally talk about is, I have the code developed or it’s developing and I have to take it, create a DevOps pipeline and deploy it somewhere.  What goes needlessly without talking about it is the data on which your application is dependant that is very important.


So if you have a product in environment and you create a test environment a lot of people that we see, a lot of clients that we have worked with before, all they do is they see the data and they create a new database, they try to recreate the scenarios from the data that they have all let’s say reverse, they try to generate the data of the scenarios that they have and needless to say it doesn’t suffice [0:12:00] all the testing scenarios and something on the production happens, you are not able to recreate it, you are not able to debug it because of the loss of data or you don’t have the data for regenerating that scenario internally, a lot of problems right?  Creation of environment is the trouble, replication is the trouble in the test environment and that causes problems that no one wants themselves to be in.  Now this data virtualization space, when bundled with the DevOps solutions gives us a totally different dimension of doing debugging or handling the root cause analysis or let’s say creation of on demand environment where you don’t see seeding of data, you can work with the same scale of data as your production setup without the additional costs, that’s wonderful, so that is what is the third one which also brings into picture, what about [0:13:00] the solutions, data are being provided by vendors as a single one stop shop?  Something like let’s say I have a software or someone says I have a software which takes care of DevOps as a whole and the DevOps setup right from the CI through the CD part.


So this is where I see another trend chipping in, that people are moving away from vendor locking situations, so they want them to be in a place where a specific set is handled by specialists, so let’s say we have CI for a special tool or we do CD with another one, we do provisioning with yet another one, configuration with some different setup, monitoring with some other tool and login with some other tool that gives us specialists in different areas.  So people are moving towards that which reduces the costs, reduces the burdens, keeps the teams nimble. [0:14:00]  Another reason for layoffs right, it can eliminate that at all so this is another trend going on, so we will have specialists coming in for every separate section where the DevOps [Inaudible] [0:14:12] will be talking about assessments, tracking your state and building everything together, just crafted specially for your organizations.  So this is where it is leading and the companies will keep coming and going but we all are looking at that, we all have witnessed it, five years down from now, it will be a completely different world than today.


Jay:  Great! So because obviously technology is evolving, as you already pointed out with the various tools and the agility and the virtualization and such,  as you look into your crystal ball and you look out, the next five and ten somewhat years, [0:15:00] what do you think the DevOps market will look like?  How will those initiatives be different then than they are now, how will that change processes as we know them today in 10 years?


Ashish:  10 years is a lot of time and the reasons for that but the way I see the future coming, the boom in the DevOps market as we see today would not last for more than five, six years from now but that’s what I think it would be.  The DevOps market would be saturated in coming five, six years so everybody will know what they are doing, everybody will have proper skills and personnel so carry on with the services.  The era post that part is the interesting one that I believe.  What I see is that in DevOps people will — so remember where I talked about people trying to [0:16:00] avoid a vendor [Inaudible] [0:16:01] situations or bringing in specialists for a particular domain, the DevOps ecosystem will be broken down into various different verticals.  So we will have specialists for particle verticals let’s say CI specialists or CD specialists or deployment specialists.  So it would be an either field with all specialties and the rules would be called as we see it in a couple of larger organizations, they are called site or liability engineers, we will not have a DevOps space anymore.


We will have reliability engineers talking about end to end systems all by themselves rather than going to some other party and then setting up DevOps for them.  Just like it was for agile way back when everybody was trying to adopt the things but now everybody is saying that we are doing it ourselves so there is no boom in that.  Similarly for [0:17:00] DevOps space, this is the right time that we do DevOps in the coming five years or six years, this is the most vibrant brilliant time that we could be in for the DevOps evolution to happen.  The next phase is going to be the phase of specialties, that’s what I believe in and a couple of more things that would contribute to DevOps in the way that we have never thought about is machine learning and AI space.  A couple of vendors have already started using machine learning in DevOps areas but the interesting part is how does everyone contribute to that?  So that is the newer dimension that we should be looking at and prepare ourselves for the next six or seven years or maybe for the sixth year to ten year duration from now.


Jay:  Excellent! I like the idea! Machine learning is very powerful and interesting.  I want us to bring us back though to the present because there were some statistics a few years back [0:18:00] talking about the failure of DevOps initiatives and I can’t remember the data but it was a higher percentage than most would expect and so I am curious, in your perspective when you talk to companies who are working on DevOps initiatives and you are helping guide them along that path?  What are the biggest challenges that you see them facing as they are going their DevOps journey?


Ashish:  To answer that in one word, the word would be called heat.  So people fail to realize the heat transition creates or when you want to transform or change, that is the most difficult thing an organization has to go through but after the change that is the most beautiful thing that the organization could look like in future.  The same is with DevOps transitions, [0:19:00] when we go to clients we talk about things that we want to offer to them, the problems that you would be solving with bringing in DevOps, we understand that its not just about tools and we don’t keep people in the dark and fool them that okay, it is just going to be about tools and setup this tool and you will be done, we tell them about everything that needs to be known to all levels of stakeholders.  And that being said, when we talk about that, they are aware of all of the things happening so we can shut down a part to avoid or maybe reduce the heat to the minimum but when that doesn’t happen, people always complain about DevOps failures, they talk about low rate of production, they say we tried doing this particular tool, we tried putting in this particular tool or a solution, we brought in this vendor but it failed [0:20:00] miserably, our teams were not able to adapt, they were not able to adopt a new tool, they were not able to change their way of thinking or we tried to do automation but it failed in production environment, a lot of problems so then they start giving up on the new initiatives okay?


So it is all about well planned strategies, if an expert comes in who is aware of all these failure parts of it, remember this is all about the cultural aspect, it’s not about technology at all.  I have seen people do DevOps with just a bunch of stones and sticks so it would be just your [Inaudible] [0:20:40] scripts, your shell scripts and nothing else.  It’s not about fancy tools or let’s say something like [Inaudible] [0:20:48] coming in or other people coming in and we need to setup that in order to call ourselves the DevOps company, no it’s not like that.  So if the solution that you are bringing [0:21:00] in is brought up from bottom.  So in agile, when we practice agile we talk about self monitoring teams, self innovating teams which bring up solutions by themselves and the solutions should grow or let’s see evolves and brought up from the bottom up in an organization, not backward related or forced top down, because when the top down forcing happens, the people who are responsible for actually implementing it is the bottom line and they get all the heat right?  When the things are forced down and that does not work in DevOps space because it is a lot, cultural aspect then it is technical when someone chooses a tool and then simply says that hey, this is the tool, we will be using this one from tomorrow onwards, get on board in on it, it’s not that easy as that right?


And that is the major problem, another problem is people not [0:22:00] being able to understand the requirements that DevOps implementation has.  Very first, a higher organization must be sponsoring that, they must buy into the complete concept because it’s only because of the support; the lower hierarchy channels for hiring people can take up the responsibilities and work on it.  Another one is understanding that it requires change in some hierarchical ways, the ways your teams communicate, the ways they are structured, it needs some change if not always but sometimes that is another one.  The third point that people generally look over or are not able to understand is the way the work should be introduced, so at different levels in an organization or at different levels of organization maturity, we have got different ways of [0:23:00] injecting DevOps into their work fields whether team structures might be different or you set up an example before the rise and they can evolve to it or you take up an existing project and then try to inject DevOps into it or you take a fresh one and then try to spread it horizontally into your organization or you take one thing at a time in an organization which is well structured and try to then seed in into the mindsets.  There are numerous different things that you could do but that is only possible when you allow an expert to walk in and do an expert analysis on your state and then come up with a plan, that what suits you best because what I believe is every organization is different right?  They do their business differently and they are the ones who understand their business the best way they can [0:24:00] and when it’s at the technology part it has to go with the business stakeholders, it has to follow the company’s reason.  Every company who is doing software development, has got it’s own strengths, they have got their own people who are good at something, if we don’t understand that part and simply say that we want to do this without understanding what you are truly good at, it is going to be a failure isn’t it?  So that’s what I have seen but if you seek help from someone who is willing to help you out, leading you through the way, understanding and telling you what the risks are and trying to mitigate in them, there is definitely going to be a success for both of you.


Jay:  Thanks and that gets to my final question and  I am sure there is additional insights you can provide which is, when you are thinking or talking to companies about [0:25:00] DevOps and DevOps initiatives, what is the top advice that you normally provide to them or put it in a different way, if I am a company thinking about implementing the DevOps initiative what would you advice me to do to prepare myself to be successful so that my project will achieve my goals and not fall short?


Ashish:  Very first thing when we talk about DevOps implementation or let’s say adoption is that, talk to an expert first because it is like doing self medication without having proper assessment done right?  And things may go wrong and definitely everybody needs a godfather who can help them out when they are in trouble.  So with a new project that is coming in, when your team is not accustomed to the newer [0:26:00] things right, and you walk in, you seek help to someone, that is the first thing that everybody should do rather than only filling up online forms which claim to be self assessment forms and giving you the idea of nothing where you stand over right?  It’s not going to help.  When a person walks in here, so this is your situation, understands what your company goes and what you are trying to do, he might be able to help you out and that might also be free because you are simply seeking an advice and it is completely welcomed that you try to do things your way but seeking help is something that everybody should do, that’s a gentleman’s thing to do right, everybody does that.


The second one is to try out the plan of adoption, it’s not something that you do everything at once, so DevOps for me is not a revolution that happens, [0:27:00] its evolution and it’s a slow steady paced evolution.  If you try to eat everything at once and trying to implement DevOps, that is going to be a failure so that is a piece of advice that I would give companies who are trying to adopt that.  So seeking advice, second go with the evolution flow, don’t try to create a revolution around it, that won’t help, another one is you try and [Inaudible] [0:27:27] the plan which is timeline based and not being so stringent on the timelines, the timelines should be setup by the teams who are in your company.  Another one is to look out for the pitfalls in DevOps, so that is very important.


Things you should not be doing, rather than the things you should be doing, because everybody claims that they are doing DevOps and not everybody claims that they are really high gainers or leaders in that right?  I have not seen anybody say that we are [0:28:00] experts in DevOps implementation in our company.  We have heard everybody say that we are doing DevOps but we don’t know where to go with that so we want someone to bridge in the gaps because like I have told before, everybody is good at something, they have the workspace, they have got skills, they have got people who are good at some part or the other of DevOps so we just need to connect the dots together right?  So understanding what not to do to important, something like not setting up goals that are stringent, putting in one single tool at a time, choosing something, or let’s say if you are making a decisional tool, make sure that it is something that you think you will be going with for the next two or three years if not five years down the line, five years is too long a span.  So two or three years because you need to connect the dots together with other tools and create an ecosystem for yourself, so that is required [0:29:00].


Analyzing your own skill sets is very important, when you have a pattern developer in your company who is willing to automate stuff for you, why do you seek someone who will be simply bringing up a tool and putting it in you company?  Another one is not talking about a complete ecosystem at once, so I said implement things at once but your plan should be five years from now right?  How it would be looking five years from now, what kind of changes do you see in people, in teams, the way projects are supposed to be built and when you have a goal to reach, you can then combine views from different teams, people and stakeholders together to come up to a technical conclusion.  So bringing a technical conclusion or drawing a technical conclusion is the final thing that one does when it comes to DevOps implementation, it’s not the first thing, people do the reverse part.  They bring in [0:30:00] the technical parts first and then try to work it out to the company goals which is going to be a failure.  We try to move it reverse, company goals first, your skill set second, come up to a conclusion, what are you trying to solve and then try to keep it down and really heat it up and take the gist off, think that this is something that we need to implement.


That is always going to be a success for you and doing one thing at a time is very important because with DevOps we are only trying to bring in agility, we are trying to complement the agile culture that we are having and when we are trying to do so, we also need to be making sure that we stay nimble, we keep that agility within is, if someone tomorrow says that this feature that we are working on needs to be change, we should be in that position because when the logins and larger solutions or comprehensive solutions that people are bringing to the market, this is not possible [0:31:00].  It becomes very difficult, let’s say you are with a tool for five years, you have all the data into it which was okay for you until now but now you want to transform, to keep your pace with the technology in the industry that simply doesn’t happen right?  So these are the pitfalls, if one takes care of it and does the right thing it should take care of itself because your teams would be driving all the innovation, they will be taking all the ownership and they will be driving the change for you which is the best possible thing an organization can ever witness, everyone working for the same goal right, rather than it is forced downwards and that’s what my views are on that.


Jay:  That’s really helpful thank you, and thank you really for your insights on this.  That is all of the questions that I had for you but I wanted to pass it to Gio, for some final words [0:32:00].


Giovanni:  Ashish, John, thank you so much for the insights today, I think it was insightful, educational and super helpful.  Again, you just heard a conversation between Ashish Nanotkar, John Annarelli, Jay Livens, and myself Giovanni Tropeano; I want to thank everybody for taking the time today to be part of the conversation and also to listen.  If you do have any questions, you can check out and

Looking for DevOps help?

Access the DevOps Checklist

Recent Posts