Posts

The magic devops button

It has been a while since I have blogged. It just we are crazily busy and some thing had to take the toll. But here I am, more fresh and with more experiences to share. Here I go. In a recent discussion with a DevOps expert, I was asking him what is that dream you want to achieve as a DevOps engineer. His answer was quick. “Culture apart, I need this – big and bold – button called ‘DevOps’. Development teams click on it and it does all the magic.” I thought that was a very nice abstraction of the DevOps dream. If it could find magically who the user is and manoeuvre him through what he wants to do, it may bring a good amount of simplicity to him. A great way to bring self service! To make that happen, there is, of-course a ton of automation that need to go into the button, but is that it? Will DevOps end in extreme amount of automation so all can be bundled in a button? That got me thinking. The questions come really afterclicking that button. Who clicked on that button? H
Post a Comment
Read more

Go DevOps try continuous Insights

Like most at my age, I am forced to watch my weight and diet! I have lived through seasonal changes of weight going up and down without really having to do much! Of course, there have been pangs of emotions to focus on weight, leading to reduction through a serious diet and exercises, but they have always been short lived. This sinusoidal nature of gaining and losing has not really bothered me all along. But a few years back, in one of those emotional push, I had joined a course on diet and weight reduction, where they taught me to measure my weight and other parameters around it, on a daily basis and write down what I ate the day before. While this was something I did, I had not given enough importance on what it meant and how I could have used it. But I guess, it is now opening my eyes. For the past year, I am at it again! I have pulled out those track pants, walking shoes and am back at it. This time I did one thing differently. Measure only one parameter – Weight. I am sure t
Post a Comment
Read more

HOW SHOULD MANAGEMENT ENGAGE DEVELOPERS?

It was in one of those meetings, a senior leaders from a large company told me, ” You know, when I was a team lead, I had such a good time interacting with the team – I knew exactly what they are working on, how they were working and how I could support them. And I knew exactly how I can make a difference in their life. Today, I have a much bigger organisation under me, but I don’t know exactly what those individual contributors are working on? and no clue on how I can make a small difference to them and hence multiply those small differences to affect change in the company.” This got me thinking. He was absolutely right, the higher you go, the less you know about the individual contributors, but you have more individual contributors under you! “The larger your ability to make a difference, the lesser visibility will you have to bring that difference. An irony of life!” But I believe, you can actually make a big difference to these individual contributors even when a large orga
Post a Comment
Read more

CONTAINERS OR NOT, APPLICATION CENTRICITY IS THE KEY

Image
While containers have stormed into the mainstream of ops infrastructure, it is now time to take a step back and think about how can you really leverage them to your advantage. You now have a very fast and effective “Ferrari” at a small percent cost, but is a container really what you need? Will you be able to handle it? Will it be an effective solution? Or only add more chaos to an already messy set up? The world of containers is about immutability—use it then loose it. It is understood that fixing an infrastructure issue is more expensive than building a new one from scratch. While that is a great solution from a infra perspective, will it help allow an application to be delivered faster and with greater consistency? Will the business see a measurable difference in service levels? Containers come and go, Applications are here to stay In such a case, the focus has to be on  Application centricity  and building the container infrastructure to help manage applications in a
Post a Comment
Read more

DEVOPS DEBATES: IMAGE-DRIVEN OR BUILD-DRIVEN DELIVERY

In the last 12 months, Docker and the containerization paradigm has challenged the foundation of some of the software delivery principles. People are resorting to things that were unheard of 18 months back and are now using them to successfully deliver software faster and cheaper. One such thing is the debate around build-driven delivery vs image-driven delivery. Over the last few decades, software has been packaged and built by a build system and tagged with a number; testers aligned their testing to the tag as the entity being tested and promoted them until it reached production. The build number was one of the most important tag for anyone to communicate about the status of the software in the delivery pipeline. For some time now—primarily due to Docker—several teams are moved to a methodology in which the image defines the version of a software. Every change in application program and deployment program will together create a new image, which is tagged and used as the version
Post a Comment
Read more

DEVOPS DEBATES: MONOLITHS VS MICROSERVICES

From the time software came into existence, application software has been booming to leverage the benefit of the computing paradigm. During this cycle, it has transformed decades of design and architectural thinking, and has crossed all aspects of application development and management needs, be it configurability, reusability, maintainability, scalability or security (a good list is of these “ilities” is here). While many have been addressed, one “ility” that has turned a lot of eyes and attention in the last few years is deployability. More than that, it is the ability to do so continuously. This requirement has changed the thinking of building software for two main reasons: (a) Businesses have started asking to release software faster than ever, even in verticals unheard of before; and (b) Cloud and infrastructure as code has made faster deployment a easier possibility. When you look at application design with deployability in mind, given the need to be agile, what you end up ge
Post a Comment
Read more

5 DESIGN CONSIDERATIONS WHILE BUILDING MICROSERVICES

The above was my topic at the  microservices day  held in Bangalore few weeks back. I thought of summarizing the discussion in this post. The motivation for this talk was to share our experiences while migrating our platform as a set of microservices. We implemented them using Docker containers and deployed both on Kube and ECS. So some design directions do take containers into account. So here I go with the top 5 design considerations, in no specific order. I don’t expect any of these to be new but thought of bring a few that I thought as important to think about. Self Containment We have been talking about separation of concerns as a architectural pattern for a long time now. This extends the same principle in making each microservice self-contained. Self containment can be achieved by various dimensions. The first one is around requirements – each requirement are such that a microservice can pick it up independently. The second is on teams – each team can independently t
Post a Comment
Read more