Blurring the line between software development and operations

Tag Archives: devops

If you ever had to handle a big marketing campaign on a website or a promotion on your SaaS product, you probably know that sizing your servers to handle the anticipated load is notoriously hard and costly. Typically, you need to get beefy hardware to power up a number of servers and deploy a load balancer to equally split the traffic between each server so you get a system that can handle millions of views in a small time range like hours.

If you read my post on the OperatingDev blog or the Precursor Games case study on theTriNimbus site, you know that we recently worked with Precursor Games to design and implement a scalable deployment architecture for their crowdfunding campaign. We chose to deploy the system on AWS and our aim was to ensure the servers can handle up to a million page views in the first few days. Continue reading →

“We are a small team,” said Otto, the CEO of a promising startup in the social media space, “and we let development to deploy changes directly on production.”

“We don’t have much custom development,” said Pam, the IT manager at a small manufacturing shop in the cosmetics industry, “and we mostly do integrations with our ERP. There is no need for a staging environment.”

“We hire the best developers and our code is fully unit tested,” says Rupmeet, who manages a team of seven developers working on an analytics product in the cloud, “thus we don’t have problems deploying directly in production.”

In last week’s article, I have argued that most software code is at what I called maturity level 1-3 and only those teams that practice coding as a deliberate discipline achieve level 4. At this level they are controlling every aspect of their deployment, like configuring the application, managing shared libraries and third-party dependencies, deploying or migrating their database, etc. They are also taking advantage of scripted builds, continuous integration and automated testing, which are pre-requisites for successful adoption of agile and lean methodologies.

But there are two more levels (and maybe more can be achieved through innovation) that are pushing the limits of what is possible with code. Arguably, these levels are only possible thanks to advances in virtualization and cloud technologies and may be beyond reach for certain type of software products that have to deal with traditional infrastructure or where the maturity of the tools available is making it harder to go beyond level 4. (Those projects are possibly limited more by tradition and mindset than tools, though.)

I am often asked to give advice on the most important processes a software team needs to implement for managing their code. The discussion usually moves from version control, to branching and merging strategies, unit testing, code reviews, static code analysis, build automation, continuous integration, test automation, code coverage, stress testing, etc. But one aspect I find as important as all of the items above is the scope your code controls. That is, how many things sit outside your codeline and how can you ensure your code is complete.

When you think of code, what comes to mind first? The lines that define your application features I presume. But those features don’t come into life in a vacuum, solely from your code — unless you’re coding The Matrix that is

A friend who got interested in concepts like DevOps and Infrastructure As Code after I introduce them to him, recently forwarded me an article in PC Magazine about something called Software Defined Networking (SDN). Being passionate about technologies that virtualize hardware infrastructure and allow you to programmatically manage your resources, I was immediately intrigued and decided to look up more information. After all, as the map on the right indicates, the IT landscape is very complex and if Dev & Ops can be put to work together by using a software driven approach to typical infrastructure needs everyone should be a winner.

While advising a client how to properly implement agile methodologies like scrum recently, I was talking about the importance of automation to their team and mentioned that automation starts with standardization. What I meant was that to reduce the cost of automation they need to standardize the platforms and technologies they use for development and production. The reaction from their people got me thinking. Their response was ‘Are you saying we should ask everyone to use only one programming language? We are a small company and we have been trying to attract talent by letting them choose the best technology they think will help them do their work.’

Operating Dev came about as an idea inspired by DevOps, which aims to bring software development and information technology closer. While the definition of DevOps may still need clarification, a major focus of this blog will be on the gap that DevOps is trying to fill in – the disconnect between software development and IT operations. I would like to use this blog to discuss DevOps and additional related practices and methodologies in an attempt to share some of my learning with other people and get feedback from the readers.