- Tell us a little about your organization: Based in Zurich, we offer consulting and training services since almost 20 years. We see ourselves as an independent enabler for the digital transformation, helping our customers getting fit for the digital age. To this end, we use the ‘Glenfis Principle’ – a holistic approach that, alongside theoretical knowledge, attaches particular importance to the mediation of practical skills (competence), which can be used to successfully and lastingly deploy this knowledge in the company or organisation (Implementation).
- What other topics do you teach or consult on? Topics include:
– Cloud & Sourcing
– Lean, Agile & DevOps
– Value Chain Service Models
– Training and Awareness (Cloud, ISO, ITIL, Cobit, Security, Agile, DevOps)
– Security & Cyber Resilience
– Change Enablement - What type of interest in DevOps are you seeing in your region? As everywhere the interest of DevOps is rapidly growing, in Switzerland this in not different. For many it’s really to understand in a first step what DevOps is about and why it is relevant for them. In Switzerland we deal a lot with financial institutes with a high level of legacy and regulations, the question is often how to apply DevOps practices in such an environment.
- How do you think that DevOps contributes to the business’ value stream? DevOps is all about getting faster and better and this is how it positively influences the value stream. And DevOps does it in a holistic way by looking at the value stream end-to-end, from idealization to $$$.
- What topic area in DevOps excites you the most? Dev’s and Ops’ finally talking to each other!
- Why should enterprises and individuals consider formal DevOps Training? Before starting any change initiative, it is paramount that everybody gets a common understanding. This is especially true for DevOps, as it includes a wide range of Agile, Lean and ITSM practices. A training or special awareness sessions definitely facilitates this.
Tag: devops
-
REP SPOTLIGHT: Glenfis AG
-
REP SPOTLIGHT: Xellentro Consulting Services
DevOps Institute: Tell us a little about your organization.
Xellentro: Xellentro Consulting Services LLP is an emerging global provider of project, program and portfolio management, IT service management consulting and training services. Established in 2012, with headquarters in Bangalore, India, Xellentro works closely with its clients in tackling their most difficult organizational development challenges. Xellentro is a specialist organization that works with its clients to identify improvement areas and uses experienced consultants to enhance their business and development processes.
While the realm of management consulting is vast and a number of firms provide a range of advisory services—starting from niche areas to general management domains—what differentiates us is our practitioner’s approach where we don’t limit ourselves only to advisory and rather prefer to stay on till envisaged benefits are realized and final outcomes are delivered. We bring in huge experience across industry verticals.
DOI: What other topics do you teach or consult on?
Xellentro: ITIL Foundation, Intermediate, Practitioner, Expert, Scrum Master and Product Owner, PRINCE2, PRINCE2 Agile, MSP, MoP, PMP, Lean Six Sigma
DOI: What type of interest in DevOps are you seeing in your region?
Xellentro: There is interest mainly from corporates.
DOI: How do you think that DevOps contributes to the business’s value stream?
Xellentro: This will be a good extension to the ITSM and with Agile being used everywhere, DevOps will have a great value.
DOI: What topic area in DevOps excites you the most?
Xellentro: The concept of having both Development and Operations working together is very important to finally deliver value to business.
DOI: Why should enterprises and individuals consider formal DevOps training?
Xellentro: To really understand the culture change and not focus on only the tools/automation part of it.
-
DevOps Q&A: SUMO Heavy’s Brodie on the Hybrid Cloud
Not every expert says DevOps will enable the hybrid cloud. One says it never will. Find out why in this Q&A with Bob Brodie, partner and CTO of SUMO Heavy, a digital commerce design and development firm.
David Geer: How will DevOps enable the hybrid cloud?
Brodie: I do not feel that DevOps enables the hybrid cloud. Hybrid clouds are very complex, and DevOps would need to be supported by a team of network and system engineers. The beauty of being on the cloud is that it’s API-driven. You can provision servers and configure and deploy with tools that are easy to set up.
Bringing dedicated servers into that environment which do not have tooling to match the cloud counterpart means that it can’t be solely maintained by a DevOps team, but rather needs much more support. We have worked in hybrid cloud environments, and have experienced firsthand the amount of effort and resources required to create and maintain a hybrid cloud environment.
Geer: What makes hybrid clouds more complex than being either fully in the cloud or fully dedicated?
Brodie: When mixing dedicated servers with cloud servers on the same network, you will likely need parallel VPNs set up so you are not sending your data unencrypted over the internet and so that if there is a networking issue there is a fallback. Setting up full-duplex, parallel VPNs can require both expensive hardware and specialized resources to configure and maintain that hardware.
Geer: Why have tools such as some of the ones AWS is building (OpsWorks On-Premises) not hit the inflection point where these are making it easier to enable the hybrid cloud? What other tools are examples of this?
Brodie: OpsWorks On-Premises is just one tool that AWS has. They also have VPNs to connect your dedicated hardware to your virtual private cloud. These tools aren’t necessarily to make it easier to run a hybrid cloud, but they allow you to utilize existing AWS provisioning and deployment tools to set up and deploy to your existing infrastructure.
Geer: Why do you think these tools never will make it easier to enable the hybrid cloud?
Brodie: Hybrid cloud infrastructure is inherently more complex than being fully dedicated or fully cloud-based. They are two different types of ecosystems, and are managed differently. They require different skill sets and levels of experience within those ecosystems.
Geer: Please expand on your following statement: “The problem is that the methodologies behind the two schools of thought (Separate sysops and dev versus DevOps) are vastly different in thought and practice, and to really bring dedicated hardware into a cloud-based architecture is very cumbersome, especially if the dedicated environment is not utilizing complex virtualization.” What does the difference in schools of thought have to do with it? What does bringing dedicated hardware in have to do with it?
Brodie: My point here is that “DevOps” is often misused. It isn’t a tool, it is a mindset. It’s a combination of development and sysops. A “hybrid cloud” is a mix of dedicated hardware and cloud infrastructure. My main point here is that DevOps practices do not make managing enterprise developments easier across hybrid cloud environments. Hybrid cloud environments are inherently more complex than the alternatives (dedicated hardware or fully cloud-based).
The reason for this is that development is becoming more and more intertwined with sysops. For example, five years ago you could download MAMP onto your Mac and be fully set up with a PHP & MySQL development environment. Modern PHP development requires a developer to understand specific versions of PHP and MySQL, how to manage them, how various applications communicate with each other and, often times, many other applications (Redis, MongoDB, Queueing systems, etc.). These can be complex to maintain, and even if they are distributed to developers from the ops team, it will often be in the form of Vagrant boxes or Docker files, which the developer will be required to understand.
This is the nature of the “DevOps” school of thought, versus the traditional “SysOps separate from development” school of thought. The target environment needs to be considered when developing an application. For example, if the application will reside on AWS then the developer will need to have a solid understanding of the tools available on AWS (RDS, EC2, ElastiCache, etc.). The maintenance of these becomes part of the developer’s job, which was not present in previous times. Adding the extra complexity of a hybrid cloud means that the developer needs to understand the underlying network architecture of that system.
Geer: In what way is the hybrid cloud a settling point, mostly built on marketing?
Brodie: Hybrid cloud environments are not ideal. They are costly to maintain and provide more points of failure because of the networking between them. What it can do is provide a halfway point for CIOs that are reluctant to move to the cloud, so they can see some of the benefits on the cloud side and hopefully move their organization to the cloud.
Geer: What are organizations afraid to let go of?
Brodie: Many organizations are scared to move to the cloud. They may have a CIO/CTO that is afraid of “losing control.” I have seen many environments such as this.
-
Continuous Testing: Shift Left and Find the Right Balance
You may have heard the term “continuous testing,” but are struggling to understand what it is and how to achieve it. Project teams need to improve their ability to test and perform test automation when needed, not just when possible. Service virtualization allows teams to test earlier and more often in the life cycle, or “shift left,“ by mimicking unavailable systems. Combining test automation with service virtualization enables teams to provide immediate feedback on quality—so issues can be resolved faster and cheaper. Encouraging and embracing this immediate feedback on the quality of the solution enables businesses to deliver high-quality innovative solutions to the market quickly.
In addition to shifting left by using service virtualization, finding the right balance of effort across all testing practices is crucial in achieving continuous testing. The diagram below shows the key test practices that enable continuous testing, and teams spend effort on each of these practices regardless of whether they want to. The questions below may help your teams understand where they are spending time, and perhaps where their time might be better spent.
- Defects – Are teams spending too much time logging, triaging or analyzing defects? What about time spent on defects that aren’t “real” defects—where there is a misunderstanding between the test and the code? Or what if they could prevent entire schools of defects from ever being created in the first place?
- Test Management – Are teams spending time manually crafting status reports and rolling up test execution results? Or do they have a tool that provides that information in real time and allows stakeholders to drill down as needed? How do teams know if they are on schedule with their test effort, behind schedule or even ahead of schedule?
- Test Automation – How efficient are teams at re-executing existing tests? Do they run most or even all of them manually? If they’ve automated tests, are they focused only on functional tests at the user interface layer, or are they running functional API-layer tests, performance tests and even security tests? Do they have a robust and maintainable test automation framework?
- Analytics – How do teams know which tests they should run, when and even why they are running those tests at those times? How good is their test effectiveness–meaning, are they running the fewest number of tests that find the largest number of problems? Impact analysis is critical in selecting the right sets of tests to execute whenever they get a new build.
- Test Environments – Are teams constantly waiting on test environments to be provisioned and configured properly? Do they run tests and discover after the fact that the test environment wasn’t “right,” so they have to fix the environment and then re-run all the tests again? Do they hear from developers, “It works on my machine!” but it doesn’t work in the test environment?
- Service Virtualization – Are teams waiting for dependent systems to become available before they can “really” test? Are they using a “big bang” approach to conduct end-to-end system testing, where they throw all the components together and hope they work and interact properly? Can teams test exception and error scenarios before going to production? Are they testing the easiest parts first just because they are available, and delaying the high-risk areas for the end of the testing effort?
- Test Data – Do teams have the needed sets of production-like test data to ensure they are covering the right test scenarios? Are there exception and error scenarios that we can’t execute because they don’t have the right sets of test data?
If any of these problems or ideas resonate with you, here is guidance on how to get started on the journey to achieve continuous testing.
First, identify your bottlenecks:
- How good is your test efficiency – are you able to run the needed tests and provide feedback quickly?
- How good is your test effectiveness – are you running the fewest number of tests that find the largest number of problems?
- Bottlenecks may also be upstream or downstream from actual test execution effort – are you waiting on dependent systems, or test environment provisioning?
Then, look at all aspects of your test effort and focus on the largest bottlenecks first.
- How long are your delays in test environment provisioning, and are the environments accurate when they are provisioned? If delays are too long and environments aren’t correct, automate your test environment provisioning and configuration to eliminate manual errors and gain accuracy and reliability.
- Are you waiting on dependent systems to start testing? If so, use service virtualization to simulate those unavailable systems so you can start testing sooner.
- Are you unable to run all the needed tests before the next build is available? If this is the case, automate your high-risk regression tests to improve test efficiency.
- Do you find performance problems late in the life cycle, or even in production? Outages can result in long-term damage to a business, so conduct load, performance and stress testing earlier in the life cycle.
- Do you find significant problems when all systems are integrated? Identify and agree upon system interface and data definitions, and create automated integration level tests for the high-risk integration points.
Teams that improve their test efficiency and effectiveness significantly reduce their expenses and the time it takes to get high-quality, innovative solutions to users. You can’t test everything, and you can’t automate all your tests, so it is critical to find the right balance. Also key is service virtualization, which allows testing to begin as soon as a build is made by mimicking missing dependencies. By combining test automation and service virtualization, teams can test earlier, or “shift left,” so they gather feedback faster than ever.
Learn more about using service virtualization to shift left and avoid downtime in test environments in our upcoming webcast: How Maersk Uses Service Virtualization to Shift Left and Avoid Test Downtime.
About the Author / Marianne Hollier
Marianne Hollier is an IBM and Open Group Master Certified IT Specialist in application development. She has strong, practical expertise in measurably improving the software development life cycle and driving the necessary cultural changes to make it work. She is instrumental in architecting, tailoring and deploying the IBM DevOps best practices as well as appropriate software development tools on many types of projects, from large to small, long to fast-track, agile to traditional. Marianne is especially passionate about all things testing—process, tools, culture and automation. Her experience is broad-based, spanning both custom projects as well as standard software packages that apply to many industries, including refining, pharmaceutical, telecommunications, health care, financial, automotive, government and retail. Connect with Marianne on LinkedIn or Twitter. -
Should You Embrace DevOps in Your Business?
New to some, old hat to many and a source of ambiguity to more than a few, DevOps is being embraced by the IT world as an answer to increase quality of business processes—to innovate faster and to get new products to market sooner in a defined time frame. There is no doubt DevOps has fundamentally changed the way an IT organization works and how it gets things done.
But one may argue what, exactly, does it mean? Is it a process? A methodology? A paradigm? A platform? A technology or a culture? DevOps is not a platform or technology, but a practice that requires internal cultural changes where working together is encouraged to reduce complexity and remove the siloed setup while ensuring the stability of service delivery.
In simpler terms, DevOps is an evolution of agile software development that aims to break down the “wall of confusion” between developers (Dev) and operations (Ops) team to collaborate better so they can deliver frequent changes faster, with higher efficiency and robust quality based on market demands.
Let’s have a look what Gartner has to say:
“DevOps represents a change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach. DevOps emphasizes people (and culture), and seeks to improve collaboration between operations and development teams. DevOps implementations utilize technology — especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective.”
Once you have a firm grasp of what it is, we can move forward. The critical step is to assess your business environment and processes for DevOps compatibility. The assessment questions could be:
- Are you meeting your project timelines?
- Are your build, deploy and test processes automated?
- Is your development and delivery cost rapidly increasing?
- Do you need more stable operating environments?
- Do you want to improve customer satisfaction through frequent and timely updates, immediate feedback loops and continuous improvement?
- Are you ready to break down the traditional silos across teams and ready to go faster?
If you’ve answered “yes” to any of these questions, then you may want to consider DevOps as a service for your enterprise. But before you consider it, the critical first step is to research your consulting partner. Look for a partner that has a long-term vision and a clear, tightly integrated road map to help your business realize the true benefits of DevOps. So whatever your drivers are for undertaking the initiative, your partner should have the requisite skills and experience to guide you on your journey. Alongside, your partner should offer you a complete range of services. From initial discussions through to delivery and ongoing support.
There’s a lot to be said for DevOps. In a business climate that’s all about speed, quality and delivery, it’s critical that enterprises understand the power of DevOps. It is not a fringe movement; it has now become a key part of enterprise IT planning to stay relevant in the marketplace.
About the Author / Ritesh Gujrati
Ritesh Gujrati is digital marketer at OSSCube, a global solution provider. He frequently talks about disruptive technologies like DevOps, digital transformation, big data, IT modernization, IoT and cloud. He is well-versed with web analytics tools, paid media marketing and has hands-on experience on organic promotion and content marketing. Feel free to contact Ritesh through ritesh.gujrati@osscube.com. -
DevOps: Keep the Business in Business
I remember when data centers were not the multipowered, multitelecommunication, hardware, software and people buildings they are today. My first was on the fifth floor of a parking lot and the cars drove around us. The importance of IT, while seemingly crucial to the business functioning of the third largest bank in the great state of Texas, was not deemed significant enough to have a modern data center.
Texas is in the hurricane belt, so five to seven months a year we play hurricane roulette. One year our city was enveloped by a Force 4 hurricane, which we survived. Our competitors, already hit by various economic factors, did not escape. But the good news was that the bank allowed us to build a proper data center.
Business continuity management (BCM), or keeping the business in business, is not just about disaster recovery. BCM is governance on risk, management of what happens if you are in the news the wrong way, employee-handling, decision-making … well, everywhere, really that keeps a business in business. Beyond people and buildings, technology is the main ingredient of enabling a business and should strongly contribute to any BCM effort.
DevOps and BCM
The concepts of DevOps are not new: How do you best manage the technology (people, processes and the fun stuff) that enables a business or mitigates obstacles? By blending the practices from Agile, Lean and ITSM, you create a better, faster, safer way of working across the organization.
If technology sustains and improves business processes and customer products, then it stands to reason that DevOps and business continuity work hand in hand.
DevOps encourages you to think in terms of the entire value chain of events. Release management, for instance, is the chain of events that ensures what is being created is delivered for use as soon as possible and with high quality, and is able to be supported. Sometimes, processes work together such as budgeting (how to use money and other resources) and funding (using money or other resources).
If you use Agile practices, then you already have the basics of release, deploy, test, change and support processes integrated. Why not add an aspect of BCM to your functional requirements and user stories, or to your “what happens if” scenarios? In this way, from the beginning of the chain to the end, everyone involved can look for, design against, test and be ready to support those occasions.
Metrics
Ranger4’s favorite metrics are cost of delay to help prioritize and meant time to recovery (MTTR) to ensure that the response, review, repair, recovery and return are as quick as possible. Great metrics impact decision-making immediately and drive change in behavior.
BCM can help to underpin these metrics by asking:
- Events will happen, so are we ready?
- Where is our code? What is our plan for infrastructure/cloud?
- How long can we be down and how long to recover?
- Where are our suppliers? What happens if they cannot respond?
- What if our data center is down but the business is forced to evacuate?
- Where are our documentation checklists? Remember that plane that landed in a river at New York seconds after lift-off? Not a long time to read a manual, so we need an easy and automated checklist.
- How will employees service their staff and customers in the event of an event? I know from firsthand knowledge that the first thing taken away from companies in a major crisis is mobile service, as almost all bandwidth goes to emergency services. So what will you use?
- What happens if a political event occurs, such as Britain leaving the EU, for example?
- How will customers contact us? How will we respond?
Answering these questions will keep the flow of technology able to service the business with the right level of feedback and response. If you continually look for ways to improve business processes using technology, then you have started to mature DevOps and the use of the three ways—and, more importantly, you have impacted the culture, automation use, customer-employee focus, ways to measure and the sharing of knowledge to make you better, faster, safer.
Being able to prove that you can survive is a great way to impress current and future clients. Every day there’s news about a company that lost a component of its technology or was impacted by an event. How often do you ask yourself: Where was their BCM strategy?
About the Author / Daniel Breston
Daniel Breston is the Chief of DevOps Transformation for Ranger4. Daniel has 30+years leading IT Service, Operations, Applications, Data Center and service partners in management of technology enabling business processes and functions. He has also spent 15 years of consulting and coaching leadership teams across the EU and UK in developing their people, processes and use of technology to deliver technology services better, faster, safer. Daniel has qualifications in IT Service Management (ITIL, COBIT,etc.), Lean and DevOps. -
Pokémon Go Shows DevOps Changes Human Behavior
Everywhere you go lately, you can see people acting strangely. They’re walking streets they never walked before. They’re waving their smartphones around in odd ways. And they’re high-fiving each other for no apparent reason.
And they’re doing it because of DevOps.
Of course, not everyone immediately thinks about Pokémon Go as an artifact of DevOps—but that’s what it is. It is code written, continuously modified and continuously promoted to production based on changes in workload performance and user feedback, implicit and explicit. It is also the most downloaded app on iTunes ever.
More importantly, Pokémon Go is visibly changing human behavior. That’s something worth considering as organizations seek to survive and thrive in the application economy.
Doing Things Differently vs. Doing Different Things
Most development is done so that customers or employees can do things differently. There are lots of apps that make shopping easier or deliver better analytic insight for decision-making. And those apps certainly provide business value by removing obstacles to revenue or by helping companies optimize allocation of resources.
But Pokémon Go doesn’t merely allow people to do something differently. It drives them to do something entirely different—location-based and augmented reality gaming.Pokémon Go isn’t the first or only app that changes human behavior. Uber and Zipcar changes how we get from place to place. Square changes how we do retail. Pokémon Go, however, is an especially dramatic manifestation of how apps change behaviors. People are doing something they’ve never done before because of some software—and because that software “went viral.”
That’s an important concept to bear in mind as organizations seek to optimize the effectiveness with which they leverage technology in their businesses. Are you just trying to write apps that help your users do something a little better? Or can your apps enable and inspire entirely new behaviors that people will find worth embracing—and therefore will also promote across their social networks?
The Role of DevOps
DevOps is central to this endeavor in several ways. First, when you’re doing something new, you by definition don’t know what you’re doing. So you have to keep going through cycles of testing to get things right. If those cycles are slow and you don’t take the time to test all possible use cases—such as geolocations, devices, operating systems, hardware, diverse transaction, etc.—because you have trouble putting the right test data together or it takes too long to provision the necessary environments, you will either be late to market or release something nobody likes.
To avoid these types of pitfalls, you need a streamlined and automated end-to-end DevOps pipeline that optimizes your delivery value chain and eliminates constraints and dependencies across the software development life cycle. Implementing this type of continuous delivery tool chain will allow your DevOps teams to continually improve the quality of your applications in a shorter time frame.
Second, even once you get things right, they won’t stay right for long. The folks at Niantic were most certainly surprised by just how viral their app went, so they had to scramble to overcome performance issues in the field. They also are dealing with some negative feedback from true Pokémon aficionados who are not so smitten with how gameplay diverges from their long-beloved Nintendo brand.
Niantic’s ability to keep riding its initial viral download success will be closely tied to its ability to address these issues. And that’s also best done with an automated DevOps process—along with Agile disciplines—that allow the company to keep refining both its code and the way that code runs in production and ensuring the performance of the IT infrastructure that supports the user experience of the app.
Luring the Wild ‘Customon’
Perhaps the most powerful lesson from Pokémon Go isn’t for developers. It’s for business leaders. Unfortunately, many non-IT executives still view DevOps and related investments in digital capability as an operational issue for technologists—rather than as an existential issue for the business itself.
But it is decidedly the latter. Pokémon Go isn’t just about having a good idea for a game—any more than Dollar Shave Club, which Unilever just bought for $1 billion—it’s about having a good idea for a company. You have to be able to execute. And in the application economy, you can’t have execution with speed and quality without DevOps.
So if you’re still struggling to get upper management to invest in funding your DevOps initiative, maybe it’s time to put away the PowerPoints and pull out the Pokémon instead. We’ve rarely had a more dramatic example of how applications can impact human behavior—and how the ability to get code into production quickly and successfully can impact your business.
About the Author / Aruna Ravichandran
Aruna Ravichandran is vice president of DevOps Solution Marketing and Management at CA Technologies, responsible for cross-portfolio solution marketing for DevOps across the Application Performance Management, Infrastructure Management and Continuous Delivery product lines. Before joining CA Technologies, Aruna held several management positions in product marketing and engineering at Juniper Networks and HP. Aruna earned an MBA and master’s degree in Computer Engineering from Santa Clara University and holds a Bachelor of Science degree in computer science from Bangalore Institute of Technology. -
Good News: DevOps is not One-Size-Fits-All
Want to try something fun? Ask different groups around your organization what “DevOps” means. It’s fun because the odds are good you’re going to get very different answers, many of which will be vague, if not outright contradictory. This is perhaps unsurprising when even industry-recognized DevOps luminaries tout varying definitions, approaches, tools and methods.
Here’s what’s not so fun: trying to figure out how DevOps might look at your organization, and what resources and amount of time it would take to do it right. The one thing upon which everyone seems to agree is that “DevOps is a good thing” and something organizations ignore at their peril, in light of the significant competitive edge it provides.
Here’s the good news: DevOps is not one-size-fits-all. In fact, there are many different facets in defining DevOps relative to your purpose(s). This article will identify some of the axes along which the answers to those questions fall, and sketch how they contribute to the overall picture. By the end, you should be better equipped to navigate your organization through the resulting, thoroughly non-Cartesian witch-space that is DevOps today.
Axes and Allies
My use of “axes” in the previous paragraph was neither random nor merely picturesque. It was chosen because it’s a bit of a chameleon, the only English word that can be the plural of three separate noun forms. In short, you don’t know what the word means apart from context. The same is true of DevOps.
Linguistic pedantry aside, DevOps grew out of the organizational friction between developers and operations, hence the name “DevOps.” But the DevOps movement pearl unquestionably has been layered and shaped by the oyster of today’s development trends: the increased (if not nearly exclusive) focus on web and mobile applications. This is simply because it’s an easy fit, those products often being much simpler to build and deploy than legacy applications.
This gives us the first axis: the industry (or industries) in which you compete. If you’re building the next great social networking site—please don’t, I beg you!—you’re going to have a tough row to hoe. And you’re going to have to do at at the speed of Web whatever-dot-oh. Because continuous deployment isn’t an option for you; it’s your personal Obi DevOps Kenobi (your only hope). Yet, at the other end of the spectrum, even the most legacy-heavy manufacturing concern can benefit from DevOps principles, though the requisite pace of innovation should be rather lower.
Industry also can determine the degree to which you accumulate necessary but hard-to-satisfy stakeholders. In the medical industry, for example, keeping your compliance department happy is both essential and more than a full-time job in itself. The DevOps drive to deploy quickly will run straight into the sort of bureaucratic inertia one expects in a heavily regulated industry. You’ll likely need to temper your DevOps expectations and shape your processes to deliver and archive additional content if your industry is more legacy than modern.
A second axis around which DevOps revolves is the type and level of maturity of products you deliver. The more you lean toward legacy products, languages and processes, the more you’ll likely need to scope and direct your DevOps efforts differently, depending on the answers to a variety of questions. For example, it’s rather a different thing to build, test and deploy a monolithic C++ application than an app intended for the web or mobile devices.
Ask yourself: How complicated are the true essentials of your build process? Which parts can you tighten? Can you isolate and prebuild components and leverage an artifact management system? What build artifacts must be retained to satisfy support, compliance and other stakeholders relevant for your industry? You’re going to need tools that can handle the load in every sense.
Similarly, how much testing can you realistically automate for the best payoff? And what sorts of testing will give you the strongest guarantee of success for the effort? Unit tests are a good start, but have you automated your all-up functional tests? What about UI testing? Stress testing? Again, the type of industries you serve and the type of products you create will generate different test demands and degrees of time and effort to automate your test suites.
A third axis along which to evaluate DevOps is your organizational culture. I’ve heard “legacy” defined as code lacking unit tests, but this seems incomplete. I’d suggest that, in fact, there’s a legacy state of mind as well, by which I refer to the sort of inertia that accretes in products and organizations over time. You’ll find it expressed in “the way we do things.” If that phrase is a discussion-ender at your organization, then you’re going to have a much more difficult time embracing DevOps.
What allies can you bring to the table to push for necessary change? Attending a DevOps conference or event can connect you with experts with experience in your industry who might be able to recommend materials. The more your organizational attitude “leans toward legacy,” the more you’re going to need a thick bench of allies to make DevOps a reality.
Leaving a Good Legacy
If it seems as though I’ve been hammering on the notion of legacy in all its forms, I have. But it’s important to recognize that legacy isn’t always a bad thing; in fact, legacy applications are essential to a non-trivial fraction of our world. Not every need can be met with a web or mobile app. It can be very difficult to tame the legacy beast in all its forms, but it’s nearly always possible to at least trap it in a well-defined cage, then shrink that cage over time.
DevOps principles can raise your game no matter how legacy your industry, products and personnel are. But it’s important to understand where you fall on all the relevant axes to determine the right scope, methods and tools to deliver the most value. DevOps isn’t one-size-fits-all, but it can be tailored to fit in at your organization.
About the Author / John Williston
John Williston is a veteran software developer for Windows, .Net, and the web. He is currently a product marketing manager at Perforce Software. -
An Even More Modern Continuous Integration
It would be strange for me to tell you that there is an even newer new approach to release automation, as if the processes of continuous integration (CI), continuous delivery (CD), continuous deployment and canary releases were not modern enough. And it would be even stranger to say that the open-source tool Jenkins, which dominates more than 60 percent of all release automation processes, is not enough for some, according to Salesify. But right now, I’m going to make the claim that all of the above is true.
DevOps teams are impatient. They always want better. It is part of the enthusiasm that continuously pushes the modern delivery chain forward. But, of course, this change has to be throttled. This is why I look to companies who have found the proper mix of sustainability and modern tooling. When I met with TapInfluence, I was surprised to find out that even the “modern” tools of 2015 are not enough for the demands its applications are putting on application releases. And its new delivery chain is a powerhouse for releases and quality.
Tapinfluence is a SaaS platform for initiating and managing influencer marketing campaigns. The company has 60 employees and growing with engineering based in Mountain View, California, and HQ in my home state of Colorado. Up to this point, the application has grown organically from a minimal viable product (MVP), which was driven primarily by a stream of requirements that came up and then adopted, to an established web application built on modern development principles. The incremental improvements are in the spirit of modern development, but it did not make for a sustainable delivery chain—or a delivery chain at all. The company lacked the practices of release automation and infrastructure you would expect.
That is why when Tapinfluence raised its latest round of funding, it was not only meant to grow sales and marketing. The funding was also intended to build a more mature development operation to keep up with the growth of the platform and make sure all the new functionality did not come with technical debt.
Kabriel Robichaux became the first director of engineering, and boy, did he have a lot of cool stuff to bring with him. Nearly from day one, Robichaux was preparing for team growth (from four to an estimated 20 team members in the next year), and significant changes to modernize the infrastructure and processes in the existing development team. This included Docker and a new release automation tool called Codeship. It was Codeship that got my attention.
Robichaux had a lot of experience in releases automation already. “I have lots of experience with Jenkins, but working in a startup, a hosted CI solution was a key feature.” But, of course, cloud-based is not the only thing. After all, you can put Jenkins in your own cloud fairly easily.
But Robichaux’s top considerations went beyond the purely technical and into their relationship to the community. He explained to me that when he adopts tools, he finds alternatives to the most popular tools, and checks them all out. He looks at tools from not only the perspective of their core functionality, but also whether they are committed to growing the market.
So we’re not talking about a new generation of release automation. Release automation is just a workflow tool. It is how the tools approach the market. And it is a tremendous coincidence that he works for an influencer marketing company, and made a deliberate choice to look at how Codeship influenced the market. “I loved Codeship because they have an opinion, they are consistent with it, and they share it. For example, they believe that everything should be in source control, and so do I.”
Considering that I work for a company rooted in developer communities, I have seen this social aspect of tool adoption as well. And it is growing rapidly. Given all the noise, it is not enough to have one or two features that do things better than the other guy. You have to be something more than a product or brand. Getting back to tactics, full control as also imperative.
He said, “I need to be able to customize everything without jumping through hoops. I want to launch it, get to the terminal window, and start adding steps. The release automation tool, if working properly, should be transparent. I want to focus on the steps in the process, not how to run the tool.” Showing that he understands that there is an effort cost in utilizing and being an expert in a tool, which should not be required.
The other element of a modern release automation tool (assuming you are on the bandwagon of the container-driven pipeline), is the container-native status. Codeship and CodeFresh, two relatively new tools, are both hanging their hats on container-native applications, and assume you are running your application on containers and/or microservices.
Tapinfluence is one of a handful of paying Docker customers. And they are taking it one step further than most by Dockerizing their entire development environment. “In 30 minutes, someone could go from having nothing on their machine, to a full dev environment and ability to commit and deploy,” Robichaux explained, which is critical, as he not only has to support the core development team, but also data scientists who know how to code, but do not know the ins and outs of the application or how to create a build they can work against.
“Normally it would take three or four days of training to get someone up and running,” Robichaux said. Given the pace of the changing environment, he simply can not waste time getting new devs going.
Tapinfluence’s application runs on AWS, and it uses Convox to manage both its developer and production instances. As he said above the source repository is key, and Git is central to everything. Git is where all the vetted Docker Compose files are stored. The DevOps teams vet the core images, and developers manage the delta for the particular service they are working on. The net result is a unified delivery chain that can do a release within five minutes.
If I were to speak with Robichaux even a month from now, I would likely be shocked again at the amount of change his company has gone through. But, it is keeping an application up and running and delivering the results its customers expect.
In the true DevOps spirit, the goal should always be to push the needle toward faster, more frequent releases at a higher quality. If you stagnate with one stack, you will not be a DevOps environment by the end of the year.
-
Delivering DevOps’ Business Value
DevOps is an interesting space to be operating in right now. More than just culture or a set of tools and processes, DevOps delivers speed and agility that can be truly meaningful for the business. Unfortunately, for most large enterprises, the path to the benefits isn’t always well-known and isn’t assured.
Over the last five to 10 years, a number of DevOps tools and solutions have emerged: Puppet, Chef, Jenkins, Git, SaltStack, Elasticsearch … and the list keeps growing. Originally, these tools were sought by developers and system engineers for their ease of use and low cost of ownership: You could download it, use it the same day and solve your specific problem. The issue for enterprises, however, is that nature abhors a vacuum; the problem one developer addressed with Chef is being fixed with Puppet by another developer in a different business unit. Group A is using Jenkins, Group B is using Chef Delivery. In short, after five to 10 years of technology adoption by developers and system engineers, the tooling landscape in the DevOps space is packed to the rafters with competing technologies, all of which are solving similar problems with overlapping features.
So why should this matter to you at all? Without careful planning, consideration and execution, your business will derive little value from this DevOps exercise.
Here are a few common pitfalls we see far too often:
Too Many DevOps Tools Doing Too Few Things
Building Rube Goldberg devices looks neat on paper, but those mousetraps fail very often in real life. The more tooling and solution handoffs you have, the greater your likelihood of failure: the less likely you are to be able to scale horizontally or vertically, the more toolsets you need to maintain, and the more skills you need on your team. Convoluted messes do not yield speed and agility. If it feels wrong, it probably is. If it is overwrought, look to remove complexity from the landscape.
Reintroducing Risk and OpEx Spent on Menial Tasks
As an organization you’re onboarding risk, hidden costs and a lot of the things you just spent the last 10 years automating away: tribal knowledge, lack of governance, lack of compliance, lack of third-party auditability and reporting. Many enterprises spend millions of dollars making it so their admins and developers could spend time on more valuable workstreams, just to throw them back into the salt mines of making continuous integration (CI), continuous delivery (CD) and infrastructure-as-code “work” over umpteen toolsets. The goal isn’t for DevOps to “work”; the goals need to tie to some tangible (i.e. measurable) business benefits. Anything can be made to work, but far fewer IT programs deliver value. Be the people who deliver real value.
Taxation Without Representation
All of the stakeholders need a seat at the table. Whether that means forming a SWAT team from operations (all infrastructure domains and security), development, QA or a permanent DevOps matrix organization, all vested interests need a say in how the process and tooling develops for all impacted domains (which is just about everything) across all environments (i.e Dev, Test, QA, Production). Far too often we see one set of stakeholders acting as the service provider for another group of stakeholders playing the role of customer. This is a solution for and by Development and Operations.
Congratulations, you’re having a baby. Let’s make sure it’s not ugly, okay?
About the Author / Jesse Langhoff
Jesse Langhoff is co-founder and CEO of Raindance, a cloud and automation consultancy serving enterprises nationwide. With over 15 years of experience in leveraging technology to address business challenges, Jesse works with customers to determine the optimal path to meeting their goals through the use of automation and solutions provided by the leading vendors in the space. Areas of expertise include strategy and assessments, private/hybrid cloud services, process automation and orchestration, DevOps and operations as a service. Jesse holds an MBA from University of St. Thomas – Opus College of Business.