devopsy.kinsta.cloud

Author: contributor

Starting with DevOps from Day 1

The Not So Minimal MVP

In the ever evolving startup space, developers often skip crucial steps in their haste to get to market. Even more so, in the dynamic app development market, the common notion of an MVP (minimally viable product) allows developers to iterate versions of their product based on issues and feedback. Seen in the context of horizontal technologies like Facebook and Twitter, the iteration period is where the real magic happens. Historically, the first versions at the “MVP” stage were bare-bones. That was then, this is now.

As apps get better, people’s expectations are getting higher. This puts more pressure on startups to have an impactful product from the get-go. Features that used to be new and fascinating are now the expectation, so startups must adapt to have a strong 1.0 as a foundation for iteration. I recently saw an ad for a company calledCircleci whom I know little about, but the tag line was brilliant; “Launches are dead, long live iteration.” Apple and Microsoft may still have ‘launches’. Startups iterate.

One way Zipline achieved a high-standard first version was by adopting DevOps via Rackspace DevOps Automation Service from our inception. Instead of migrating our app over to a more mature platform after many iterations, we decided to make the investment early. Here are just a few reasons how adopting DevOps from day one can help position a startup on the cone of a rocket ship:

1. Understanding Scalability

There’s a line of thinking that goes like this: First comes product, later comes scalability. We strongly disagree. When people hear the word scalable, they think upwardly increasing capacity and size. So it can wait, right? For startups, downward scalability is just as crucial. While most startups view DevOps as an option for the future, we found success by leveraging DevOps from our inception. Instead of waiting to implement a mature infrastructure like DevOps, we looked for partners that could give us access to managed services typically only available for big companies. We found success with large scale systems that were downwardly scaled to match our business need. DevOps gave us an opportunity to work with systems that were ahead of us in terms of technology and culture. Startups who view their product as agile, dynamic and iterative, but DevOps as only a static-run environment are making a huge mistake.

2.Understanding Culture

Hiring and retaining top tech talent is difficult –even more so for startups. But we noticed something profound as we grew our development team from one to seven: Talented engineers who interviewed with us expected our infrastructure to be novice. When they realized that our DevOps infrastructure rivaled that of the big company where they previously worked, their minds were put at ease. I’m not saying it always closed the deal, but it signals to a growing team that they are part of a winning culture. Building a winning culture starts from day one.

3.Understanding the Cost of DIY

Most developers capable of writing quality code are also capable of creating an environment to run the code. The cost seems so innocent at first. For a bootstrapping startup, common sense says “do it yourself”. Again – wrong.

Nothing is more costly for a startup than distraction. Every minute should focus on your unique competitive advantage. I’ve never heard anyone say, “I use this technology because of their awesome DevOps.” What makes your company great? Strong DevOps for startups should eliminate distractions, sharpen focus and accelerate code commits.

4. Understanding Collaboration

Walk into most mature tech companies and you’ll notice something: The development team and operations team are separated into different spaces. Startups should exploit this vulnerability to gain a competitive advantage. Collaboration in small startups should be instant and in real-time. At Zipline, deploying DevOps from day one promoted a culture of open communication across all people involved in delivering our application. According to the Rackspace DevOps Automation Survey, 41% of organizations have seen better collaboration amongst project teams and 35% have seen more accountability across developers and operations for getting apps to market after deploying DevOps. Running a collaborative system allows us to focus on elevating our product in innovative and creative ways.

5. Understanding Iteration

Every system at a startup should iterate constantly. Take something mundane, like bookkeeping. If your system of keeping books isn’t better on Friday than it was when the week began, then you failed. The death of a startup can occur quickly. Iterate or die. So ask these simple questions every Friday, “Is our DevOps better than it was on Monday? If so, how? If not, what can we do to change it next week?”

About The Author/Kirk Bowman, JD

Bowman is the founder of Zipline Labs, Inc. A life-long entrepreneur, Kirk loves applying the mental rigor he honed as an attorney to creating innovative businesses that shift perspectives and evolve behavior. His endless curiosity and capacity for complexity unearths opportunities in the least likely of places. Now, he’s focusing his thought leadership in the financial sector. As founder of Zipline, Kirk is exploring how people relate to money and how technology can support an evolution to financial systems that are more social, more connected and more human. A master storyteller, Kirk is a compelling voice when evangelizing for his belief that if we can shift the way we feel and behave around money in both our personal lives and our work, we can create a better human experience.

Connect with Kirk on Twitter: @kirk_bowman Connect with Kirk on LinkedIn: LinkedIn

August 7, 2015
DevOps killing outsourcing? Another point of view

After reviewing the articles (here and here) on DevOps driving the end to outsourcing I felt it would be constructive to provide an alternative point of view. The premise of the article is that because DevOps requires close collaboration between development and operations that it would be difficult if not impossible to effectively implement DevOps in a heavily outsourced environment. Additionally the productivity advantages of DevOps would help eliminate the need for outsourcing. Therefore, organizations wishing to see the advantages of DevOps should move away from outsourcing. While I can see the advantages of that approach, I also think that companies that have to live with outsourcing can’t ignore the benefits from implementing DevOps principles with a well-designed deployment pipeline.

From my perspective, companies looking to implement DevOps first need to start by understanding their architecture because it has such a large influence on how to effectively implement DevOps. If they have loosely coupled architectures that enable small teams to independently develop, qualify, and release code then they should look to the world of unicorns for how to implement DevOps. They should look at integrating operational people onto the development team and work to evolve the culture by blurring the lines and responsibilities between the two groups. This feels like a fairly straightforward process that many unicorns have proved to be very successful. For these types of organizations, I tend to agree with the articles recommendations that DevOps would work better without outsourcing.

The problem is that most large traditional organizations looking to implement DevOps don’t have the benefit of an architecture that enables small nimble teams to work independently. They typically have very tightly coupled legacy architectures that require 100-1000s of engineers to work closely together to develop, qualify, and deploy complex integrated systems. Ideally, they would re-architect their applications so they could see the benefits of nimble independent teams. The reality though is that this is just not practical for most traditional organizations in the short-term. Additionally, they can’t wait for the re-architecture before they start realizing the advantages that DevOps principles can provide with a well-designed deployment pipeline.

For these organizations implementing DevOps principles (the ability to release code to the customer on a more frequent basis while maintaining or improving stability and quality) is more about creating a well-designed deployment pipeline that builds up a more stable enterprise systems on a regular basis so it is much easier to release the code on a more frequent basis. This is done by creating a deployment pipeline that integrates the code across the enterprise system on a much more frequent basis with automated testing to ensure that new functionality is not breaking existing code and the code quality is kept much closer to release quality.

From my perspective this approach to DevOps is rather different from the more unicorn type approach described in this article. It though does address the biggest opportunity for improvement that does exist in more large traditional organizations which is coordinating the work across teams. In these cases the working code in the deployment pipeline is the forcing function used to coordinate work and ensure alignment across the organization. If the code from different teams won’t work together or it won’t work in production, the organization is forced to fix those issues immediately before too much code is written that will not work together in a production environment. Addressing these issues early and often in a deployment pipeline is one of the most important things large traditional organizations can and should be doing to improve the effectiveness of their development and deployment processes.

These benefits are even more pronounced when working in organizations that have outsource development across multiple companies around the world. Ensuring the different vendors don’t go off track and create code that won’t work together in production is critical and a well-designed deployment pipeline is a critical tool for coordinating development across different outsourced organizations in traditional tightly coupled systems. For these types of outsourced organization, DevOps principles while different are almost more important than they are for companies that do all their development internally.

About the Author/ Gary Gruver

Gary Gruver is an executive with a proven track record of leading Large-Scale Agile transformations and co-author of “A Practical Approach to Large-Scale Agile Development” and the new book, “Leading the Transformation: Applying Agile and DevOps Principles at Scale.” He is currently working to help organizations with their transformations after successfully leading two large transitions at HP and Macy’s. As the Director of Engineering at HP, he led a large organization (400+ developers) on a journey from waterfall to agile development. At Macy’s.com, as the VP of QE, Release, and Operations, he led the transition to Continuous Delivery. Reach him on twitter at: @GRUVERGary

August 6, 2015
Benefits for the Product Team in Working Support Cases

An increasingly popular practice that’s being adopted by DevOps groups are developers working regular shifts in front line support. The thinking behind this exercise is pretty sound. When exposed to the real world problems and frustrations customers face when using their software, a developer’s work becomes more about supporting that customer experience and increasing customer satisfaction and less about “Get the tests passing and ship it fast!” The practice also increases an individual developer’s understanding of the larger solution their company provides. If a particular developer is master over a small part of the total application, working support will give them valuable insight into the bigger picture of the problems they’re solving and how well their corner of the world is supporting the larger solution.

We practice this at my company, Datical, but on a wider scale. In addition to the app dev engineers every member of the product team, myself included, regularly works support cases in direct contact with the customer. It has been a pretty eye opening experience for all of us and we are most certainly realizing the promised benefits of this practice.

Our product team operates with a single guiding principle: Well defined, customer driven requirements yield excellent solutions. When you schedule calls or take customers to lunch, you get a lot of great feedback on where your product should go and net new features you should consider implementing to improve the overall solution. The conversations we’ve had with customers in this way are generally very positive and supportive with a focus on future direction and growth.

Working a support case is an entirely different and much more crucial customer conversation. The conversation that takes place during a support interaction is centered on a pressing need. The customer may need clarification on usage that isn’t as intuitive or well documented as it should be. They may be dealing with a gap in previous requirements or a coding defect that is keeping them from completing a goal. Whatever prompted the call, it’s occurring because the customer is not delighted and we are getting a firsthand, real time account of what is problematic and what we must do better. These needs translate directly into our product plans and requirements.

But there’s more to glean from these interactions than the matter at hand. When the customer is amenable we like to use GoToMeeting to remotely look over their shoulders as they demonstrate for us the issue they are having. During their demonstration, we get additional insight into the mechanics of our solutions. How do customers interface with our products? Are there minor inefficiencies our users have to contend with that they aren’t reporting? A few of the most well received features we have delivered since adopting this practice have been very small stories that were pretty easily addressed, which removed a minor annoyance that was encountered frequently in our workflows. We’ll release these fixes with a minimum of fanfare, but they are almost always noticed, commented upon and appreciated by the customer.

The last class of lessons learned from our foray into front line support pertains to my new favorite non-word, troubleshootability. When something goes wrong, how easy is it to diagnose the problem and how long does it take? How detailed and centralized is your logging? Are users being updated on the progress of long running operations? If an error is encountered due to customer misuse, is the customer appropriately guided to correct the error? Anything that we can do to shorten the cycle and cut through the murk when something does go wrong improves the overall experience with the product and increases customer trust.

Working support in product management and engineering has been a really great exercise. It’s given us a deeper understanding of our solutions, our users, our strengths and our weaknesses. This understanding has led to requirements that are tightly focused on our customers’ needs, holistic development practices concentrated around comprehensive customer workflows, and a solution that clearly communicates what’s going on as it happens for fast diagnosis and remediation of issues in the field. I highly recommend it.

About the Author/Peter Pickerill

Pete Pickerill is Vice President of Products and Co-founder of Datical. Pete is a software industry veteran who has built his career in Austin’s technology sector. Prior to co-founding Datical, he was employee number one at Phurnace Software and helped lead the company to a high profile acquisition by BMC Software, Inc. His ability to understand product demands from a customer’s perspective and translate those demands into actionable product and development plans has led to expanded duties at every company for which he’s worked. In his time at Symantec, Pete worked directly with large financial services companies and online retailers to implement and improve online fraud prevention solutions that were used daily by millions of people worldwide. In addition to managing a development team and product schedule at BMC, Pete worked directly with large financial services institutions to provide the features they needed to achieve greater efficiency and cost savings in their application deployment processes.

Connect with Peter on twitter: @PetePickerill

August 5, 2015
How ADLM Gobbles Up DevOps

The Next Evolution of Software Delivery Automation

In the 1980’s and 90’s, the business software landscape was dominated by a diverse list of cutting-edge companies such as Best Software, i2, Brock Control Systems, Mapics, Ross Systems, Infinium, FBO Systems, Manugistics and MSA (of course I could go on and on). Now long gone, these and hundreds more really great companies have been gobbled up or rendered obsolete by the rising class of ERP giants. In this article I’ll explain why history will repeat itself leading to the extinction of most DevOps tools as leading ADLM platforms continue to assert their dominance across the diverse software development and delivery automation ecosystem.

History Informs Our Future and The Evolution of ERP

You already know that for the past twenty years, most companies have leveraged some form of ERP system to manage virtually every core business processes. One benefit of this tightly integrated solution is a powerful inter-functional data flow that enables corporate agility and provides the highest level of visibility. This super-integrated architectural model has become the standard adopted by virtually every enterprise around the globe. What you may not know is today’s “ERP model” is the result of four distinct evolutionary generations that I believe help predict the next major evolution of automated software delivery.

Phase 1 – Automation
Enterprise Information Systems (EIS) – In the 1960’s, early automation systems were developed to support important individual business functions such as general ledger, inventory management, billing, payroll, etc. These systems were architected completely independently of each other and added little value to the enterprise beyond their narrow scope.

Phase 2 – Core Data Model
Manufacturing Resource Planning (MRP) – Then in the 1970’s, the idea of a master production schedule was devised so that a few of these isolated systems could gain greater visibility into future inventory and product requirements of the organization. The big idea behind the master production schedule was the creation of an open data model that could be leveraged by other systems impacted by the manufacturing production schedule.

Phase 3 – Expansion
Manufacturing Resource Planning II (MRP II) – In the 1980’s, software vendors began to build and sell off-the-shelf packages that promised “best of breed” process design. These solutions provided tightly integrated versions of the key manufacturing processes required to produce products.

Phase 4 – Business Process Domination
Enterprise Resource Planning (ERP) – Finally, in the 1990’s, business software vendors expanded well beyond the manufacturing scope by creating highly-integrated solutions that now cover just about every standard business function imaginable. These systems leverage a unified data model to dramatically improve visibility, consistency, accuracy and planning capabilities enterprise-wide.

What Does ERP Have To Do With Automated Software Delivery?

The evolution of ERP has taught us how natural pressures forced the creation of a unified and comprehensive “business data model” spanning the entire enterprise. Those software vendors with enough influence to dictate that data model were the ultimate winners in the ERP space.

In the very first generation of ERP (EIS), software was leveraged to deliver a high degree of automation to many business processes that were previously manual. Over time, it became clear that these newly automated processes were interconnected and the evolution towards a tightly integrated and unified data model was underway. The business objective that fueled each successive generation outlined above was the need to design more efficient business processes that increased organizational visibility and agility.

As Marc Andreessen famously said in 2011, “…more and more major businesses and industries are being run on software and delivered as online services—from movies to agriculture to national defense.” (Why Software Is Eating The World). That statement resonates even stronger four years later. Today, virtually every corporate organization is seeing the familiar pressure to deliver software more efficiently and reliably. If history is indeed our guide, any highly fragmented and/or isolated process required to deliver incremental software change will face mounting pressure to be merged into an integrated end-to-end enterprise-grade platform that can deliver improved cross-functional visibility with even greater efficiency.

Why Application Delivery Lifecycle Management Will Win

In my view, there are really only two broad solution categories in the realm of automated software design and delivery – Application Development Lifecycle Management (ADLM) and the catch-all term DevOps (which I’ve hijacked here to describe any other type of process automation that assists the software delivery process).

DevOps tools are often narrow point solutions that have sprouted from open source projects, in-house development or commercial vendors. Organizations rely heavily upon a diverse collection of these DevOps tools to help document, validate and automate a steady flow of software change along its path to end-users.

Here’s the problem DevOps tools are beginning to face: Like the EIS systems of the 60’s, fragmented DevOps tools have little or no visibility into the overall end-to-end process; however, they do generate lots of important data that is often locked away and isolated. This isolation creates a clear barrier to efficiency, visibility and agility across the software delivery process. Because of the limited function each individual DevOps tool performs, none have the gravitational pull required to define the larger data model. As comprehensive enterprise software delivery platforms emerge elsewhere, standard DevOps tools will face ever-increasing pressure to fold inside them.

Currently, Application Development Lifecycle Management solutions provide a platform to manage development projects, team resources and all manner of development activities. ADLM platforms also contain the “master production schedule” for every development initiative – past, present and future. The data contained within ADLM is now at the core of a quickly emerging software delivery data model and leading ADLM vendors are expanding their footprint pwell beyond traditional use cases. When it comes to ownership of this software delivery data model, I see no other solution category across the entire ecosystem with enough enterprise clout to pose a serious challenge to leading ADLM vendors.

Unified Software Delivery Platforms Are Already Emerging

Each of the five current ADLM leaders (according to Gartner’s most recent Magic Quadrant) are now racing to bring to market an enterprise software delivery platform that integrates many key DevOps capabilities.

Here’s my two cents on each…

The Giants in the space – IBM and Microsoft both have plenty of muscle and IP today. Clearly both are moving down the path toward a comprehensive software delivery platform. IBM acquired DevOps vender urban{code} several years ago and is hard at work building their developerWorks platform. Seemingly everyday, Microsoft is adding some kind of DevOps capability into its Visual Studio product suite. Still, I don’t see either vendor gaining much traction outside of their traditional (albeit very large) customer base. Perhaps more importantly, neither seem to have bonafide credentials within the super-influential agile development community and I believe this kind of street-cred (at least for now) is a must-have to dominate this space.

Atlassian does enjoy wide support among the agile community and no doubt has the broadest adoption footprint of any of the current ADLM leaders. Atlassian is in a strong position to mount a serious threat. However, Atlassian’s core product (JIRA), is widely believed to lack heavy-weight depth in the ADLM feature spectrum and it is often implemented as a departmental or “team tool”. They’ll have to develop deeper strategic planning and multi-team project capabilities to beat the rivals.

This May, software giant Computer Associates announced a definitive agreement to purchase ADLM heavyweight Rally and its agile development platform. In its announcement, CA said it intends to leverage Rally’s capabilities to “complement and expand CA’s strengths in the areas of DevOps and cloud management”. With the crucial addition of Rally, CA is now in a strong position to assemble its diverse capabilities into a single unified and enterprise-caliber software delivery platform. Now… can they seamlessly integrate all of the pieces-parts into a cohesive solution with a unified data model? If so, how long will it take?

Finally, I believe VersionOne may have a slight edge over the other ADLM vendors in the race toward a unified software delivery platform. I may be a bit biased because of my direct involvement in a joint project currently underway – none the less, here are four reasons why they will absolutely be a dominant force to recon with:

Vision: Robert Holler, VersionOne CEO, is clearly buying into the “enterprise software delivery platform” vision. He and his team have a well thought out strategy and they are actively executing against that strategy.
DevOps Automation: VersionOne has partnered with ClearCode Labs and both teams have been hard at work integrating ClearCode’s Continuous Delivery Automation framework into the VersionOne core product. This integration provides VersionOne the ability to orchestrate virtually any DevOps tool or platform and (just as importantly) incorporate all related data across VersionOne’s product suite to fee its quickly expanding data model.
JIRA Integration: VersionOne has just announced a tight integration into the JIRA platform. This integration will give them the ability to fold fragmented JIRA installations across the enterprise into the unified VersionOne platform providing a more strategic and enterprise-grade solution.
Availability: VersionOne’s automated delivery platform is available now and they are demonstrating their comprehensive solution to the eager agile community this week at the sold-out Agile2015 conference in Washington, DC.

Summary
The top 5 ADLM vendors are already well on their way toward developing enterprise-grade software delivery platforms that will consume many of the current “DevOps” automation solutions. Soon, development organizations will benefit from a comprehensive platform that can deliver increased efficiency, visibility and agility when compared to the heterogeneous solutions that have been cobbled together today.

About the Author/Dennis Ehle

Dennis Ehle, is a pioneer and thought leader in continuous delivery automation and agile delivery methodologies. Dennis is passionate about helping agile teams dramatically reduce the transaction cost associated with delivering incremental change. His company, ClearCode Labs, does just that by helping organizations continuously deliver high-quality software releases more frequently merging proven methodologies with empowering tools and technology. Twitter: @DennisEhle

August 4, 2015
DevOps in a Hybrid Model
As enterprises have begun to demystify the value proposition around cloud adoption, several best practices, optimization techniques and delivery models have been described in the technical community around cloud enablement and large scale adoption. While the debate between choosing private cloud vs. public cloud model has been longstanding, enterprises have been looking to mitigate the level of software disruption caused by such large transformation. A Hybrid model is thus a very appealing prospect since enterprises can still technically control the security policies and governance models, while also taking advantage of capacity bursting and other benefits of the cloud.

As with most technologies, adopting a hybrid cloud solution doesn’t buy you a free lunch either. There are several complications that are being discovered as enterprises mature into this model. One of the biggest challenges is to keep the software development lifecycle in sync across multiple target environments that are the basic backbone of a hybrid cloud model. Thus, having a robust DevOps solution is one of the key necessities for making a hybrid model work.

The Business Case for a Hybrid Cloud Model

In today’s complex business world, enterprises either by choice, or by circumstances, are choosing a hybrid model of IT solution. Enterprises are best served by implementing a “best of breed” solution, which means a combination of several domain specific SaaS (Software as a Service) and PaaS (Platform as a Service) solutions. This also eliminates any risks of a “vendor-lock in”.

So by design, a hybrid model will have a combination of the following characteristics:
- Multiple platforms within an enterprise architecture
- Both traditional as well as virtual platforms
- Domain specific SaaS/PaaS solutions, typically in a multi-vendor scenario
- Lack of standardization across cloud platforms (hypervisors, hardware types supported, so on and so forth)
Now, the challenge is to make IT delivery work seamlessly around these characteristics. This is only possible by a high degree of automation in the delivery process, operations process as well as the business planning processes. Those are the very elements a DevOps platform attempts to solve.

The Challenges of Cloud Adoption

Let’s take a quick look at some of the core existing IT capabilities built into a large enterprise.
- Security model
One of the biggest challenges towards cloud adoption is the notion of extended or revamping existing enterprise security model for cloud (and as a consequence, into DevOps solutions). How can one make sure the same security policies for data classifications and user management are applied especially on a public cloud model? Will existing audit processes suffice in a cloud model? Can existing security policies be leveraged as-is or with minor modifications and still be able to take advantage of a cloud model? These challenges will drive enterprises into a hybrid solution.
- Support and Governance models
Many enterprises have built up a history and matured best practices around IT governance and support structure (think ITIL). The cloud model in many ways disrupts those practices. One of the ways to mitigate the disruption is to adopt some form of a hybrid model so some best practices and core support capabilities can still be leveraged while taking advantage of the cloud.

One of the emerging business models for enterprises is to avail a more “managed services” model so they can focus more on their core business capabilities rather than on IT. In a managed services model, one or more service providers will be responsible for portions of the overall cloud solution while the enterprise would retain responsibilities over centralized capabilities like security. So the “hybrid” nature is not just limited to physical environments, but also around support models.

Implementing a DevOps strategy could help mitigate a lot of these issues.

Hybrid DevOps Scenario

A typical SDLC (Software Development Life cycle) DevOps looks like the following.

Figure 1 – A Typical DevOps Pipeline

The aforementioned actors in figure 1 may or may not actually be “people” since in a true DevOps world, those actors are replaced with some degree of automation. But it sets the context on what types of roles & responsibilities are expected in a typical pipeline.

Now, imagine this pipeline that is multi-folds, across several application or components. This is the real nightmare of deployment and release management issues that one has to account for since in a hybrid model. Each of these applications/components may technically reside in a totally different environment developed and managed by totally separate groups with different service level agreements.

A centralized DevOps platform, standardized across these application environment boundaries (for the most part) to provide a single pane of control over code, release and deployment management is what is required for a successful adoption of hybrid solutions.

Here is an indicative centralized architecture to solve the deployment and release management issue described above:

Figure 2 – DevOps Platform Architecture Example

The components listed in figure 2 is purely indicative and shouldn’t be misconstrued as any product marketing or messaging. The main challenge will be to standardize components to the extent possible (this is easier said than done) and stitch together a meaningful platform that works within an enterprise (based on existing tooling & processes, skills, funding etc.). Bear in mind I’m merely touching the surface in this article with regards to a DevOps platform, and limiting this to a tooling discussion. Bigger challenges do exist in the form of process and organizational transformation, which are also necessary to make a DevOps implementation successful. I’ll pen those topics in a separate article 🙂

Summary

DevOps for Hybrid cloud implementations will soon become the de facto model for process transformation in large enterprises. There is simply no other way to go about such large transformation in a purist way. There is a wide verity of use cases for a hybrid model, and most enterprise situations would fall under one or more of those categories. A robust DevOps platform is absolutely critical to making a Hybrid cloud adoption successful.

About the Author/ Sunil Joshi

Sunil is an Executive Architect with IBM. He is currently the Application Development & Innovation (AD&I) DevOps offering owner for Global Business Services. He is IBM Senior Certified and Open group certified Distinguished Architect. His specialization are in the areas of hybrid cloud solutions, platform as a service and DevOps strategy. He’s created complex hybrid solutions on cloud and DevOps for large enterprises. Sunil has authored several IBM Redbooks, blogs and also a co-author of the IBM Cloud Computing Reference Architecture (CCRA).

Sunil is passionate about international music, multi-cultural cuisine, active sports and mentoring school & college students on career path and technology.

Contact Sunil on
July 31, 2015
DevOps Dozen – Nominations are now open

To succeed in todays speed of business, app-centric world the old ways of doing business just don’t work anymore. IT and development teams are being pulled, pushed, stretched and changed into new combinations and configurations. Greater cross-functional cooperation is a must, a culture of cooperation and a new generation of tools that facilitate these are changes are sweeping in like a Tsunami.

DevOps has appeared like a superhero fighting a villain to combat these issues. Featuring a one-two punch of continuous delivery and continuous integration with a finishing blow of automation, DevOps enables easier and closer collaboration between development and operation teams.

Whether they be cloud-native “unicorns”, traditional enterprise “horses” or born on the run startups, DevOps is becoming the “way they do things.”

The field has matured enough where we think it is time to recognize some of the best and brightest. Our first venture with this is our “DevOps Dozen” The DevOps Dozen will feature the top 12 vendors in the DevOps space. I know 12 isn’t a lot given the amount of companies in the mix, but we had to start somewhere.

So how do we get to a dozen from such a large and worthy group? We at devopsy.kinsta.cloud have compiled a list of what we think are the best known DevOps companies. Some of these companies have their product or service listed as well to help identify the face to the name. We have broken them down into several categories to hopefully make it easer to select (tip of the hat to XebiaLabs and their Periodic Table of DevOps for the help with that).

The DevOps Dozen selections will be made by you our readers in two phases. First we will open the whole list as well as any write ins for those we may have missed. This nomination voting will be open until August 12th. At that point we will take the top 24 company/products who garnered the most nominations. These will be the finalists and we will have a 2nd round of voting for final Dozen.

Feel free to tweet about the DevOps Dozen using the hashtags: #DevOpsDozen and #DO12

Please click here to vote for the finalist nominations

or fill in below

Create your own user feedback survey

July 27, 2015
Avoid the DevOps Tool Trap

Software development, at its most complex and dynamic is a full-court press of effort, knowledge, patience, and hard work. Anything that can reliably and cost-effectively reduce the huge number of tasks, redundancies, reports, and delays associated with the application release process is something to be embraced.

In particular, many organizations today are turning to the agile development methodology, DevOps, in order to rapidly produce software and improve operations performance. According to research by Gartner, by 2016 DevOps will become a mainstream strategy that will be employed by 25% of Global 2000 organizations. Moreover, by 2019, Gartner predicts 50% of enterprises will implement automated configuration and release management as a result of DevOps initiatives.

What many in the development community don’t realize is that solutions exist, using current technologies, to automate many of the routine—and even not so routine—elements of the application release process needed for DevOps. Instead of adding multiple application-specific automation tools, resulting in a confusing and expensive array of various silos of automation, organizations can take advantage of their existing automation suite to automate their application release processes. What we’re talking about is not simply scheduling workflows, but the actual execution of tasks, from administrative duties to build deployments, release management, and more.

Using modern IT workload automation solutions, it’s possible to offload the manual execution of a number of processes to improve overall DevOps agility. Many actions necessary to go from code to production, not to mention maintenance and cleanup tasks, can be taken off the backs of developers and operations, thus freeing them for higher level projects.

With a modern workload automation solution, organizations can automate routine and time-consuming build kickoffs and installations. For example, using pre-built job steps for Microsoft Team Foundation Server (TFS), organizations can create an automated workflow that deploys builds onto machines, installs the kits onto production environments, verifies installation files are correct, and then sends an alert to the proper users that the build is ready. After QA performs testing of the individual stories, the automation solution can then close the stories and merge them in time for a daily or weekly review meeting. Teams can also integrate TFS with a QA/test system, in order to automatically create a new work item with TFS every time a bug is logged.

On the Operations side, one of the biggest challenges in application release management is making sure machines are correctly architected. Excessive instances and regression tests can cause machine slowdowns that create havoc with development schedules. Again, workload automation comes to the rescue via workflows that purge databases, increase CPU, or anything else necessary to ensure a properly-provisioned testing environment.

Adding to this, many popular tools used in software development lack even basic scheduling capabilities. If you wish to create a work item or trigger a build, for example, you probably have to do so using a Web service or the TFS Task Scheduler Service. Even then, all you likely have at your disposal is date/time scheduling. This is where advanced workload automation really shines, since it can trigger tasks according to a pre-defined event, or even a complex combination of events. As a result, DevOps teams can avoid unnecessary project delays or lag time due that would otherwise occur with manual handoffs between teams or individuals.

While workload automation has been around for many years, today’s IT departments are increasingly using workload automation as a foundation for their wider IT systems. As new methodologies and strategies like DevOps and Big Data emerge, automation provides a foundational piece upon which to automate essential processes needed to support these new initiatives. In the area of DevOps, workload automation is helping both developers and operations build and automate release processes more effectively, with capabilities that can make the difference between headaches and headway. Don’t fall into the DevOps tool trap.

About the Author/ Jim Manias

Jim Manias is Vice President at Advanced Systems Concepts, Inc. and is responsible for the overall market strategy and planning for a range of products including ActiveBatch® Workload Automation and Job Scheduling. Jim has been with Advanced Systems Concepts since 1991 and has held multiple senior management positions in the enterprise software and hardware market. Jim can be reached at JManias@advsyscon.com

July 24, 2015
Webinar: Security Breaks DevOps: Here’s How to Fix It
The concepts of communication, collaboration, abstraction, automation and orchestration are cornerstones of the rapidly growing DevOps movement. At the same time, reliance on elastic infrastructure has exploded, making manual security provisioning and management infeasible. Applying security policies based on static parameters and making manual rule changes just before production leaves little time for provisioning the policies. This impacts release quality, increases risk of errors and slows down the DevOps cycle. Now security teams have an opportunity to learn from the DevOps experience.

Attend this informative webinar to learn:
- Common pitfalls associated with using traditional security solutions in DevOps environments
- Key ingredients to look for in a security solution that matches the speed of DevOps
- Real-life case studies of companies who have adopted DevOps methods to security
Recorded: Thursday, August 20th, 2015

Recording

Slides

[seoslides embed_id=”1be9f52bf38c” script_src=”https://devopsy.kinsta.cloud/embed-script/9139/9158/” overview_src=”https://devopsy.kinsta.cloud/slides/9139/” title=”” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” /]

Your Host

Alan Shimel, Editor-in-Chief devopsy.kinsta.cloud, An often-cited personality in the security and technology community and a sought-after speaker at industry and government events, Alan has helped build several successful technology companies by combining a strong business background with a deep knowledge of technology.

About the Panelists

Amrit Williams, Chief Technology Officer, Cloud Passage

Amrit Williams has more than 20 years of experience in information technology and is currently the CTO of CloudPassage. Previously Amrit was the Director of Emerging Security Technologies and CTO for mobile computing at IBM. Prior to IBM, Amrit was a research director in the Information Security and Risk Research Practice at Gartner, Inc. where he covered vulnerability and threat management, network security, security information and event management, risk management, and secure application development. Previously, Amrit was a director of engineering for nCircle Network Security, and undertook leadership positions at Consilient Inc., Network Associates, and McAfee Associates.
July 20, 2015
Become Tester of the Future!

ROKITT Launches Test Automation & DevOps Bootcamp & Workshops. Learn more & register for our Open House (every Monday & Wednesday, from 5-7 PM, Jersey City) at http://rokittech.com/index.php/bootcamp.

July 17, 2015
Webinar: Introducing CloudBees Jenkins Platform – your foundation for DevOps and CD with Docker Containers

Continuous delivery (CD) of applications is rapidly becoming a differentiator in this application economy. CloudBees, the enterprise Jenkins company, recently announced the availability of the CloudBees Jenkins Platform to help organizations adopt CD. This new enterprise offering from CloudBees brings CD to the masses with the new Team Edition, while enabling enterprise CD deployments powered by Jenkins at scale with the Enterprise Edition. At the same time, the Jenkins open source community, in conjunction with CloudBees, released six new plugins to support the use of Docker containers within Jenkins-powered CD and CI processes. Docker is powerful new technology that allows teams focused on delivering software to standardize their development and production application environments for reduced risk and accelerated application delivery. Leveraging Docker containers in a CD process managed by Jenkins is the ultimate way to deliver better software faster.

Join Tracy from CloudBees as she talks about Cloudbees’ new enterprise offering and the changes happening in the Jenkins community to provide first class support for Docker in the creation of CD pipelines. In this webinar, Tracy will introduce features in the latest release of the CloudBees Jenkins Platform to
help manage Jenkins’ across the organization and walk through six common delivery patterns with Jenkins and Docker. Tracy will then tie it all together with a demo of an end-to-end delivery pipeline with Docker.

Continuous delivery with Jenkins and application containerization with Docker are rapidly becoming two of the foundations of the DevOps movement. Check out this webinar to learn how you can adopt these new tools and techniques in your own DevOps transformation.

Recorded: Wednesday, August 5th, 2015

Recording

Slides

[seoslides embed_id=”3285347f9c95″ script_src=”https://devopsy.kinsta.cloud/embed-script/cloudbees-jenkins/8856/” overview_src=”https://devopsy.kinsta.cloud/slides/cloudbees-jenkins/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”Cloudbees – Jenkins” /]

Your Host

Alan Shimel, Editor-in-Chief devopsy.kinsta.cloud, An often-cited personality in the security and technology community and a sought-after speaker at industry and government events, Alan has helped build several successful technology companies by combining a strong business background with a deep knowledge of technology.

About the Panelists

Tracy Kennedy is an associate product manager for CloudBees and is based in Richmond, Virginia. Prior to her current role, Tracy has worked at CloudBees as a solutions architect and a developer success engineer. In her free time, she enjoys rock climbing, grand strategy games, and reading. Read more about Tracy in her Meet the Bees blog post and follow her on Twitter.

Udaypal Aarkoti is the Director of Solution Architecture at CloudBees. He believes in complete end to end automation and that continuous delivery is the future of application delivery. Prior to CloudBees he lead the middleware solution architecture team at Red Hat.

July 13, 2015