“…if an application moves from an environment where disks/volumes are mounted using WWNNs/WWPNs as end-point IDs (fibre channel) to an environment with IQNs as end-point IDs (iSCSI) we often have to re-validate and re-engineer. If the application were to list its own requirements it would actually just be something like ‘xGB block storage, isolated, with <performance guarantee 1> and <performance guarantee 2>’. There would be no mention of WWPNs or IQNs, fibre channel or iSCSI. The list above is the type of [automated/attached] description needed that would help make the application portable. It fits into a trust-based model (aka Promise Theory)…”
Software development practices continue to evolve and vary and this post provides a good description of microservice-based design practices. Amongst many other things, this type of application architecture plays well with hyperscale cloud infrastructure offerings inc. charging models as individual instances tend to be very small vs. monolithic ‘3-tier’ application architecture which instead scales ‘up’ by having more resources applied to instances/VMs/PMs. Microservice even allows some orgs to run on a ‘Free Tier’ offered by Public Cloud providers. There is also a reference to Conway’s Law. “In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often a HTTP resource API. These services are built around business capabilities…”
The pros of Microservice architecture and the new complexities to manage before and during runtime followed by a good overview of the infrastructure + app services platform (PaaS) evolution and requirements underneath
“The key building blocks of a modern IT organization include a highly flexible infrastructure, an automated software delivery life cycle, and a devops-driven IT organisation. These capabilities are essential to ensuring that IT remains relevant in an era of continuous change to customer-facing services and automated business operations. This report focuses in particular on OpenStack as an underlying cloud platform to support this new type of organization. In addition, it examines a handful of ecommerce and Software-as-a-Service (SaaS) providers and the challenges these companies seek to solve by adopting a more agile software development and deployment process using OpenStack.”
“Networking, not servers, is often the immutable object that is not easy to make agile. Even when working with vLans there is a spider web of IPs, Ports, Routers, routing tables, perimeter networks etc who’s interdependency can’t simply be changed, broken, moved, or replicated.”
“A long talked about theory in software development is the idea of “shifting left,” where software development and testing teams work to bring higher degrees of quality – usually through testing – earlier in the software development life cycle. The problem is that the majority of testing is not done until the service is completed—after integration and user acceptance testing—making it nearly impossible to test quality into a system”
DevOps in a large enterprise. Comments on org structure that works etc. “I now work at a ~$20 billion company with 40,000+ people. If DevOps can work here, it can work anywhere.” There’s a mention of Slack for collaboration between sites.
Why Is DevOps Different In The Enterprise? -> People, Process and Technology broken down. “There are many books and degree courses on organisational change and transformation. People can make careers out of it. It’s a complex area full of best practice, insight and accumulated experience. We need to bring that thinking into DevOps”
Yep, you guessed it… ‘as-a-service’ has been bolted on to DevOps… a comment on buying in ‘DevOps’: “If DevOps is a growth engine for your company, then outsourcing it is like building a car with the motor located elsewhere”
Another aggregation of Continuous X and DevOps news and information put together for colleagues at work but thought to be worth sharing outside of that group. * = help with prioritising what to read if you’re hard pressed for time.
The terms “Bimodal IT” and “Trimodal IT” have recently been used to describe the potential split of strategies for different classifications of IT systems – i.e. ‘old stuff’ and ‘new stuff’ and the different opportunities with each (pretty much = don’t hold up ‘new stuff’ because of ‘old stuff’ requirements – they’re different). This article talks about ‘DevOps in Enterprise’ being more successful when when addressing the ‘new stuff’ rather than being reverse engineered against existing/legacy systems.
However, if you are going to try to reverse engineer against the ‘old stuff’ to some degree then here’s a starting point. Interestingly, we have reference to where data centre tech/infrastructure services can make a different in a more generic sense: “Save that bespoke Windows config as a virtual machine, then you can subsequently redeploy it… use an enterprise infrastructure-as-a-service (IaaS), whether private or public cloud, hosted or on-premises, especially for newer applications…adopt platform-as-a-service (PaaS), either out-of-the-box or by building a PaaS that will support your unique environments”
“I recommend analyzing your business goals and application portfolio using the pace-layering method, which focuses on three categories of applications – systems of record, systems of differentiation, and systems of innovation”. Back to the ‘old stuff’ vs. ‘new stuff’ but with a bigger link to systems thinking and what can really affect the business – I like these classifications.
“There have now been 21 million downloads of the Docker platform, up from 3 million at DockerCon. Over 35,000 “Dockerized” applications are now available on the Docker Hub Registry, and more than 13,000 Docker-related projects have launched on GitHub. Docker has also seen rapid growth in the technology partner ecosystem with over 100 companies – including industry heavyweights Amazon, Google, IBM, Microsoft, Red Hat and VMware – having announced Docker–supporting platform initiatives.”
Collaborative culture, elevated & shared goals, collaborative culture, elevated & shared goals, collaborative culture… if people say it enough it will happen everywhere right? Some interesting comments from ‘DevOps leaders’ within different orgs in this document. The real question that still remains is what changes in the DevOps model in order to apply it within a large multi-national organisation? You may notice that none of the interviewees sit within an org bigger than 2000, most are in the hundreds… the question still remains.
“change management, the tools, can be detached from change management the governance. And then no longer tied to the reactive philosophy”. A practical look at opportunities around Change Management within a DevOps philosophy.
“the nearest I can come to “you’re doing it wrong” is when people announce the death of Ops as a job function…. in truth it’s very, very hard to excel in both the development and operational aspects of building and running a large computer system. These people do exist, but trying to find them and hire them is hard (and expensive). Moreover, beyond a certain (small) scale it’s actually woefully inefficient to have everyone doing everything.” Tips from someone ‘doing DevOps’.
”the company’s product, GuardRail, focuses on helping IT departments understand how their various systems are operating wherever they may be located. Instead of this information being strewn across the organization in multiple departments and locations, GuardRail brings it all to one central location”.
“Nearly half of respondents reported that their companies have missed opportunities because their IT department was too slow to respond to shifting business needs. And approximately 49 percent reported that a lack of bandwidth in IT is the primary obstacle of the organization to take advantage of digital technologies… Approximately 42 percent of organizations report that they have a poor track record of facilitating collaboration across IT and business functions.”
FYI The DevOps Cookbook is reportedly at draft/review stage. This will likely turn out to be a ‘must read’.
There is also apparently ‘DevOps Training’ for ‘DevOps Certifications’ popping up now. While it helps with the foundational knowledge side of things it is also an indication of the beginnings of a cottage industry that might ultimately break the DevOps ‘following’. With that in mind, two more articles:
Common Objections to DevOps from Enterprise Operations (Dev2Ops) -> “The quickened pace puts a lot more pressure on the centralized ops team because they often get the work late in the project cycle (i.e. when it’s time to release to production). Because of time pressure or because they are over worked, operations teams have difficulty turning requested work around and begin to hear developers want to do things for themselves….. unfortunately, a centralized devops team can become a silo and suffer from the same “late in the cycle” handoff challenges the traditional ops group sees. -> A practical view of the kind of situation ‘Agile‘ can create on the Ops side when it’s mainly Dev pushing a cultural shift towards DevOps. *
The Continuous Delivery Maturity Model (InfoQ) -> Taking five key categories, Culture & Organisation, Design & Architecture, Build & Deploy, Test & Verification and Information & Reporting, the aim of this article is to establish a method of measurement for where an organisation is with ‘Continuous X’. This particular model defines five maturity levels: base, beginner, intermediate, advanced and expert. Measuring against this model can help you to work out how best to support your customer. Image available. *
Two Ways DevOps Unlocks the True Potential of Agile (devops.com) -> “The good news is, organizations can close their gaps and realize the true value of Agile development by incorporating DevOps processes and tools into their systems development life cycle (SDLC)… The DevOps principle to employ here is getting the operations team involved in testing earlier in the SDLC – essentially shifting their work left – and the tool that can help is service virtualisation”. This article is effectively saying if Ops are involved earlier in the SDLC then they can help get QA/testing environments as close to a real-world Production environment as possible and monitor the whole SDLC. This is advantageous when considering the implications of Continuous Delivery and Deployment. “By simulating constrained or unavailable systems across the SDLC, service virtualization enables developers, testers and performance teams to work in parallel for faster delivery and higher application quality and reliability”
DevOps and Change Control (sdncentral) -> A rhetoric and some guidance on ‘if everything’s constantly changing, how do we manage and track the change?’
Why DevOps Matters To The CIO (contino) -> “technology that can be used to innovate and succeed in a competitive marketplace… the challenge of delivering technology that enables their business to succeed… DevOps is a movement and set of best practices that has a lot of value for the CIO who is operating against this backdrop.” Effectively a DevOps sales pitch to a CIO. *
How to Celebrate DevOps Success (ranger4) -> “So what might a DevOps SMART goal look like?” Metrics and rewards acting as a stimulus for successful DevOps…? Status, Certainty, Autonomy, Relatedness and Fairness (SCARF) needs to be looked at in each person’s role/group of people in the eyes of this writer.
DevOps: The Operational Amplifier (DevOps Journal) -> “Maintenance windows exist in the enterprise, after all, to manage expectations with respect to downtime and disruption specifically because of the interdependent nature of enterprise applications…..The thing is, these numbers are only going to get worse as the Internet of Things continues to put pressure on organisations” This article takes a look at the unaligned growth of IT services vs. the people operating said services. DevOps can be the tool, the ‘amplifier’ to allow a few Ops folks to manage a world of [near] exponential growth. “That means APIs – strong APIs – as well as extensibility and flexibility. Infrastructure cannot remain rigid and static in an environment that is rapidly changing. It must be dynamically configured, extensible, and imminently flexible.”*
Testing in a Continuous Delivery world (SD Times – Rob Marvin) -> “If there’s one overarching principle, it’s to automate everything” This article gives a good indication of the anticipated push of automation through the entire stack from a SDLC perspective. We at Cisco talk about automating at an infrastructure level but tying full software revision control inclusive of infrastructure services is where things are heading… i.e. Regression testing is mentioned in this article – if I regress my software, I’d like to regress the infrastructure state below it… in an automated fashion…
DevOps continues to heave itself up the hype bell curve and with that there are some very interesting reads out there. I put the list below together for my team at work, it’s a summary of recent articles that touch on different sub-areas of DevOps. I’ve added notes so that you can be selective with your reading. I’ve also put * against the reads to maybe prioritise if you’re hard pressed for time.
Security considerations for DevOps adoption -> IBM on the practicalities of incorporating good security practices into a DevOps model. They identify how open source software use and lessened checking of the software chain introduces risk. There’s also the human factor in a more ‘relaxed’ and collaborative approach (malicious and non-malicious).*
DevOps, ITIL, and Operability -> An extract from their free eBook ‘Software Operability: a DevOps cornerstone HighOps’. This delves into the operational impact on an IT org inc. managing change control etc. It also touches on “CAMS” which is based on the CALMS model (i.e. minus the L[EAN]).
Applying Lean and DevOps for better business outcomes -> A good holistic view of DevOps. An interesting mention of “IBM DevOps Subject Matter Expert (SME)”. Along with the ‘DevOps engineer’ job role there is clearly an effort to separate the skill set associated with DevOps.
Intersections: People, Process and Code -> “Application monitoring and load testing should not be considered the end of a release process. It is just the beginning. Over time, the results from multiple tests and releases in production will show how well your overall deployment process is working.” – Data and information feedback loops…
How many times do you repeat a task before it should become a candidate for an effort around automating it?
What is the risk involved in doing the task again manually after a period of time away from it?
Is it more logical to ‘script’ the task and hand a simple standardised ‘tool’ over to colleagues than write a mini guide on how it’s done or show people individually?
Can I simplify a task by hiding complexity that only an SME needs to understand in a tool that uses only widely understood and meaningful inputs?
Questions that will probably get different answers and views shared if you ask different people… which is why it’s nice when a community reduces the relevance of the questions by doing much of the work for you? (I use ‘2 or 3’ as a rule for the first question providing I could see a need for the task to be done again btw)
If you have developed PowerShell skills then you can programme against many systems in the data centre. Cisco UCS is included in this. It has a library of cmdlets. This library has been put to some awesome use in script submissions for a contest that is currently running on our Communities site. A great resource has been created on the back of that competition.
I particularly like the easy-on-the-eye bandwidth check that Vallard Benincosa has put together and the comprehensive system health check produced by Brandon Beck following great work by Jeremy Waldrop! We’ve used the system health check in our labs and it’s very handy indeed!