devopsy.kinsta.cloud

Author: contributor

The 3 Compliance Questions to Ask
As companies move to cloud, they require more certainty around export compliance.

Of the many complexities associated with cloud computing, export compliance laws arguably are some of the thorniest. From a legal and technical perspective, the export compliance laws currently on the books—as they vary from country to country—can make even the savviest and most experienced attorneys’ and engineers’ heads spin.

All enterprises must adhere to a variety of industry- and country-specific rules related to important security, data privacy, taxation and export controls. But these rules become especially murky around cloud services. For example, if a U.S.-based company provisions a virtual machine abroad, say in China, does it need to develop region-specific export controls?

Export compliance rules raise other, broader questions. For example, how do you retain agility while complying with the necessary regulations? And how do those regulations and controls vary according to workload? Like tax regulations, rules for collecting and distributing user data vary depending on location.

Not having the proper compliance protocols in place can have serious implications. Say your client is expanding into a foreign market and, at the last minute, they request a number of changes that have not been evaluated from a compliance perspective. Either the expansion is delayed, which could be damaging from a reputation and financial perspective, or the company runs the risk of being cited for compliance violations.

So, as more and more companies expand globally, how can they prepare to meet the compliance challenges stemming from cloud computing?

Three questions in particular are critical to answer when it comes to cloud export compliance.

Is it possible for companies to be both agile and compliant?

Increased business agility is perhaps the single greatest benefit cloud offers. Cloud computing facilitates rapid provisioning of resources, allowing companies to scale quickly and adapt to changing client and market needs. But what effect does export compliance have on cloud’s speed and flexibility? This type of unprecedented agility requires a re-think of how governance and policy enforcement is managed. Instead of manual checks, companies must transition to real-time policy enforcement and recording that matches the agility of cloud. This is a change to both culture and process—the rocky road where foundations can begin to crumble.

How do compliance rules vary from country to country?

Companies that operate internationally are subject to a number of rules related to citizens’ data protection, taxes, variations relating to workload, region-specific controls, paperwork and registration. When conducting cross-border provisioning, legal counsel is mandatory to establish best practices and to ensure compliance. Unfortunately, because the cloud is a relatively new phenomenon, legal expertise in this area is scant.

Further, even when there is some legal expertise, when it comes to uncertainty, the default answer from legal counsel is often, “No, we can’t do that.” Indeed, when there is a certain amount of risk and haziness around the law, the easiest—and safest—thing for legal counsel to do is to say it can’t be done. But that’s not helpful to a business.

What steps can companies take to prepare for these differing requirements?

There are three essential measures that companies can follow to help ensure their cloud services are compliant with global export regulations.
1. Identify: All software that could be subject to cross-border exports—either packaged software or homegrown code transferred between between countries—requires legal guidance and approval. So the first step is to determine the software being exported.
1. Register: Once you have identified the appropriate software, you need to maintain a registry. Whether an image or an automation routine deploys the software, it’s important that you have a clear record verifying what must be registered.
1. Record: Companies that employ cloud across borders may be required to keep a record of all export transactions. Many businesses make excuses why they don’t properly document these transactions—the virtual machines in question do not belong to them; their cloud software is publicly available; or recording export transactions is only mandatory when exporting to riskier markets such as China, Iran or North Korea. To protect companies from liability or legal action associated with cross-border data transfers, legal counsel often will suggest recording all cross-border software movement.
These steps are critical to the export process, and partnering with a cloud provider that can help clear up export confusion can ease the pain. Some cloud brokers and providers offer applications that track cross-border exports, which can save a number of headaches. They have tagging and metadata reporting systems in place ahead of time. These are necessary for security and privacy compliance anyway, so it can be leveraged across domains.

A good cloud platform provider anticipates a business’s needs and offers services that a company may have never even taken into consideration, such as tracking tools to keep tabs on software so that it can be easily reported. These companies have in-house counsel with expertise in cloud export and tactical, strategic plans (such as the metadata tracking) so you know what software is going where for how long and how often—data that can also help support audits.

Information is power, and the more you have, the more prepared you are to deal with thorny issues such as export compliance. Having a partner to guide you through the process—an experienced cloud platform provider with sound advice—can help arm you with the information you need to get to cloud quickly, safely and securely.

About the Author / Rodrigo Flores

Rodrigo Flores is Managing Director of Product Innovation, Architecture and Management for Accenture Cloud Platform. The Accenture Cloud Platform is a multi-cloud management platform that procures, provisions, orchestrates, manages and governs enterprise cloud resources.
June 10, 2016
Where’s the Heat? Talking DevOps, Use Cases and More

Transitioning your organization from a traditional IT infrastructure into the world of DevOps is certainly a journey. Sometimes a long one, with many obstacles, but undoubtedly a voyage with a worthwhile prize at the end. Many organizations just embarking on their DevOps journey find themselves wondering, what use cases should they attack first? And who is driving these initiatives?

Recently, Amy DeMartine, senior analyst at research leader Forrester, and Wesley Pullen, general manager and vice president of Deployment Solutions at Electric Cloud, participated in a discussion to answer these questions and discuss how to orchestrate the DevOps tool chain, how to approach application release automation, and how DevOps fits in the greater scheme of compliance and auditability. For folks just beginning their DevOps journey—and IT pros who have been walking the walk for years—there were some great takeaways from their discussion.

DeMartine started off the discussion with something so basic that many folks often forget to consider it before starting their journey. But it is one of the most fundamental and important steps before beginning to explore DevOps; that is, answering the question, “What is DevOps?”

Here’s a great definition used by Forrester:

DevOps provides a set of practices and cultural changes—supported by complementary tools—that automates the software delivery pipeline, enabling organizations to win, serve, and retain consumers better and faster than ever before.

Part of this is the idea of taking the huge monolithic releases of the past and breaking them up into smaller and smaller pieces—at least on the agile development side of things. Then infrastructure and operations folks get involved and complete the continuous delivery life cycle by automating builds and testing and making sure releases are consistent and fast. Finally, there is collaboration among development, operations and security to make the product even more successful than before—and in all of this, you are creating feedback loops and building quality as well as consistency.

So now that you’ve got an established idea of the fundamentals of DevOps, let’s dive right into use cases. One of the most often-cited use cases is the idea of governance. People venturing into DevOps love the idea of moving faster and delivering more quickly than ever before, but find themselves asking, “How do you do that safely?”

It’s helpful to look at this using the visual of an upside-down triangle, with governance at the top. It applies to all companies and gives them the ability to control their releases all the way from development to production. Part of the benefit of using DevOps is that all of these tools you are using are creating log files, which essentially are breadcrumbs that give you an easy way to follow an audit trail. If you’re using a standard technology stack across a single application and apply it to multiple applications throughout your organization, you have the ability to look at governance across all of these various applications through the same lens.

On the next level of the triangle is compliance, which, depending on your industry, can mean a variety of things, but they are usually predefined and concrete. Finally, the bottom of the triangle is the audit aspect, which is where the best practices of DevOps become the most important.

DevOps Drivers

Ultimately, there are three different drivers of use cases that we see in DevOps, each with unique needs and perspectives. The first of these drivers are folks involved with infrastructure and operations. We often see projects and initiatives coming down from CEOs, CIOs and other senior executives in which the operations staff is driving the initiative and ultimately is responsible, so the initiative gets the budget. This is very hot in financial services.

Another driver are members of IT ops, DevOps and enterprise architects. These members often are focused on cross-team, cross-project initiatives. These are the senior architects, developers and operations staff that all are working together on a single solution. They already have the tools in place, but want to drive and orchestrate an end-to-end solution. Whether they are doing a build or need to make a quick change to provision a server, their goal is to consolidate and have a seamless pipeline.

Finally, the development-driven initiatives are coming from senior architects, development leads and QA who are pushing all kinds of different automation aspects, including continuous integration, continuous testing and continuous delivery.

Diving deeper into these heat zones and specific drivers, it’s helpful to look at what these groups are really focusing on. The top automation initiatives within the subgroups of infrastructure and operations folks start with the need to do deployments faster. They need to drive deployment automation faster. They also are interested in release management, or coordination across a release stream for different teams. When an organization has a series of activities across multiple teams, there is a distinct need to release everything at once to make sure it works. This group also is focusing on compliance and audit—particularly in highly regulated industries such as health care, financial services and insurance—and is always driving initiatives in which it’s trying to build out auditing packages.

In cross-team-driven initiatives, members include IT ops, DevOps and enterprise architects who are focused on cross-teams, and the cross-project initiatives primarily focus on end-to-end orchestration. They also are concerned with cloud resource management. When teams are paying for tools, they want to make sure they are maximizing their value and getting the most use possible out of those resources. That can mean scaling up or down in strategic ways to get the biggest “bang for their buck.” Finally, this group also focuses on configuration management orchestration.

Lastly, developer team-driven initiatives are focused not only on items such as continuous delivery, continuous integration and continuous testing, but also on container orchestration. As there is a greater awareness of potential security holes in Docker, it is necessary to place an increased emphasis on container orchestration, particularly with more and more individuals moving to containers. There also is an increased focus on QA lab provisioning. With the incredible growth in the realms of the Internet of Things (IoT) and embedded, these areas are correspondingly heating up for developer team-driven initiatives. One example put forth in the discussion between DeMartine and Pullen was a recent issue around one of the most well-known IoT devices on the planet—the Nest smart thermostat. In January, Nest went down, leaving many people without heat. This is a great example of why development teams want to focus on IoT use cases: DevOps enables rapid fixes for the massive demands of the IoT world.

Ultimately, you can see from these use cases and initiative drivers that DevOps offers an incredibly dynamic opportunity, ideal for meeting the needs and perspectives of organizations from top to bottom—and the incredible growth of DevOps, as the organizational structure for IT organizations across multiple industries proves that out. In fact, DeMartine and Pullen polled the audience during their discussion and found that 61 percent of attendees planned to adopt DevOps practices in the next 12 months, while 83 percent of attendees planned to adopt deployment automation/ARA in the next 12 months.

If you aren’t already considering DevOps for your organization, whether you are and CEO or a developer on the front line, it is worth investigating to see how it can answer your most pressing challenges and use cases.

The full conversation between Amy and Wesley is available here.

About the Author / Sam Fell

Sam Fell is the Head of Marketing at Electric Cloud, responsible for driving awareness and demand for our DevOps Release Automation and Acceleration solutions. For 20 years, Sam has helped companies achieve success by marketing, selling, and implementing DevOps Release Automation, IT Change Management and Application Performance Management solutions. Prior to joining Electric Cloud, Sam held leadership roles at BMC, CA, Marimba and Nimsoft.

Sam holds a Bachelor of Arts degree from Illinois Wesleyan University.

June 10, 2016
DevOpsDays Silicon Valley is Coming!
DevOpsDays Silicon Valley is coming, so mark your calendar! DevOpsDays events are a global phenomenon, bringing together practitioners across roles for two days of scheduled presentations and networking in a community-organized event. You won’t want to miss this year’s conference!

The 7th annual DevOpsDays Silicon Valley is scheduled for June 24-25 at the world-famous Computer History Museum. Silicon Valley is the oldest of the U.S. events and was originally the third DevOps Days ever. The conference, which started in 2010 as a low-key event hosted on the campus of LinkedIn, has grown into a major event.

This year’s lineup includes talks from a variety of perspectives including security! Jennifer Davis, co-author of “Effective DevOps,” will open the conference up with “Devops is for Everyone.”

DevOpsDays Lineup

Here is the 2016 speaker lineup:

Keynotes:
- Troubleshooting Troubleshooters: Debug Your Colleagues for Fun and Profit, by Bethanye McKinney Blount, CEO/Co-Founder
- From Divided to United – Aligning Technology & Business Teams, by Dominica DeGrandis, Director, Learning & Development
- Cost versus Performance: Analytics for Walking the Tightrope, by Elizabeth (Betsy) Nichols, Chief Data Scientist
- The Future of Automation, by Adam Jacob, CTO and Founder of Chef
Presentations:
- Behind Closed Doors: Managing Passwords in a Dangerous World, by Noah Kantrowitz
- At the Intersection of Happy and Healthy: DevOps Meets IoT, by Gail Ferreira
- Heresy in the Church of Docker, by Corey Quinn
- DevOps Army of N – Recovering From Being a Human SPOF, by Jonathan Disher
- (Parental) Leave Actually, by Dave Dash, Nicole Grinstead, Melissa Sandgren
- How to Onboard Entry-Level Talent to a DevOps Culture, by Angel Tian and Sophia Castellarin
- Autoscaling Containers … with Math, by Allan Espinosa
- How I Learned to Change My Mind and Became a Better Engineer, by Ramin Khatibi
- Removing the Stigma of P0w3rship, by Ed Anderson
Ignites Include:
- How Do You Measure Availability? Performance and Availability and SLMs, oh my! by Warren Turkal
- Feature Feature, by Linda Goldstein
- The Elements of Developer Experience (DX) Design, by Stephen Boak
- Reflections of an Operations Burnout, by Jamie Dahl
- Breaking Brooks’ Law with DevOps, by Jason Yee
- A DevOps Team is a Daft Idea and You Should Feel Bad! by Caedman Oakley
- How Can You Scale It If You Don’t Trust It? by David Blank-Edelman
- From WWW to GGG, by Anne Ahola Ward
- How I Learned to Stop Worrying and Love the Protocol, by Pete Sclafani
Following the inspiring talks, each afternoon is dedicated to Open Space, where the agenda is dedicated to small-group, participant-led discussions chosen on the fly. This is the chance to dive into specific topics, ask for help, discuss what you’ve done, find like-minds or just be a fly on the wall and take it all in.

If you are in the San Francisco Bay/Silicon Valley area, get your tickets for the June 24th and 25th DevOpsDays Silicon Valley ($199) before they sell out. We also have a limited number of education tickets for faculty, staff and students ($100). If you live elsewhere, be sure to keep an eye on the main DevOpsDays site for upcoming events. Also, check out DevOpsDays Silicon Valley recorded talks from 2015.

About the Author / Damon Edwards

Damon Edwards is the co-founder and managing partner of the DTO Solutions, a DevOps and automation engineering consultancy whose clients include leading SaaS, e-commerce, gaming, and financial services companies. Damon Edwards is also the co-founder and vice president of SimplifyOps, a provider of support and services for the users of the Rundeck open source project. Damon has spent over 14 years working on both the technology and business ends of IT operations. Damon is also a frequent conference speaker and writer who focuses on DevOps and operations improvement topics. Damon is active in the international DevOps community, including co-organizing the DevOps Days conference series, co-hosting the DevOps Cafe podcast, and a co-author of the DevOps Cookbook from IT Revolution Press.
June 9, 2016
5 Development Trends Reshaping Testing

There’s no shortage of new development trends, but virtual reality, containers, big data, hyperconnected apps and IoT are affecting testing the most today.

If you like change and challenge, it’s a fun time to work in software. Some technology developments, such as cloud computing, have been gaining speed slowly over many years. That steady progression has meant that developers can stay on top of trends easily and be informed about market changes. Other areas, such as containers, have come to fruition much faster without as much notice. Development teams have had to scramble to stay ahead of these trends, hoping to capitalize on a their efficiency gains while staying ahead of the curve. Here’s a look at five important software trends which are having a profound effect on testing.

Containers

Docker made containerization cool and exciting in 2013, even though containers have arguably been around for many years, if not decades. Developers love containers because the technology makes it much easier to set up and install software in different environments, such as in the public cloud or in a private data center. Containers wrap up all of the infrastructure components that otherwise would be installed separately into one easily portable package with a common standard. And since multiple containers can run on the same hardware without creating problems, you can do more with less infrastructure. Typically, containers can move between different environments with relative ease—a nice benefit for multicloud infrastructures. Containers have evolved quickly from an experimental platform to a mainstream infrastructure technology, with many major businesses taking advantage of containers to deliver their product at scale.

Testing considerations: It’s hard to find much at fault for containers when it comes to facilitating software testing. Because of the ease in setting up test environments and moving code from one environment to another during the production cycle, testers can work much faster. Before containers, there was a lot more waiting around by both developers and testers. When it takes two weeks to set up an environment for a testing cycle that took two hours, teams would tend toward less frequent releases or would do less testing. Now, it is a matter of minutes to set up a testing environment. This is great for companies and development teams that value testing and want to test more frequently with greater access to a variety of environments.

Another boon with containers is stability. In the past, bugs sometimes appeared due to configuration errors from setting up dev/test environments. Given the plug-and-play nature of containers, there’s little if any concern about the proper configurations being completed before a testing environment can be used. Security has been an ongoing concern with containers, especially in highly regulated sectors such as health care, government and financial services. In those cases, companies may have to support two versions of the code—one in a containerized platform and one in a more traditional virtual or bare-metal environment. We believe this will be a short-term situation as containerization technology matures and becomes adopted across all industries.

Big Data

Whether you want to use this vague and overhyped term or not, big data is simply a new way to refer to larger than normal data sets. Big data became a big trend as the hardware and software to store and manage it got a lot more powerful and cheaper, and the cloud shift helped to centralize data sets into one location. Some large companies and research organizations are seeing interesting results from big data projects already, whether in more targeted drug development (precision medicine) or just-in-time environmental data for farmers. Now, every Tom, Dick and Harry is trying to get into the big data market, which means there are too many solutions to count. A natural weeding-out process will occur over the next few years, as the prominent big data players and NoSQL standards converge into two or three leading providers.

Testing considerations: Big data applications bring value through the way they manage and/or analyze data, not so much through the user interface. Therefore, testing for big data applications is going to require more technical, database-oriented skills. Those skills are also different from the typical relational database skills of the past, given the fact that big data platforms typically are designed to manage structured and unstructured data. These are open source tools and systems such as NoSQL and Hadoop, along with large vendor systems such as SAP HANA. Testers in this field will need to be constantly adapting learning these new technologies.

Virtual Reality

Investors have funneled $8.8 billion into the sector since 2012, according to SuperData Research. Google, Facebook, Microsoft, Samsung and HTC are all in the game. The market is segmented between VR, augmented reality (AR) and mixed reality (MR) and consists of both traditional (PC/console) and mobile device applications. VR is a fully immersive, fully virtual experience that mimics reality, while AR and MR are different variations of blending real and virtual environments together. VR applications aren’t just for gaming anymore: We now are seeing the technology being used for product design and collaboration, tourism/travel and entertainment, including film.

Testing considerations: VR is an emerging technology still, with many different types of platforms, no clear leaders and no real standards in place. That makes it more difficult for developers and testers to make strategic decisions around technology. As well, there aren’t any great tools for automated testing in these environments yet. Therefore, the need for manual and real-world testing will add time and cost to the project. Yet, investing in doing this right is critical for ensuring optimal user experience. In virtual reality environments, it’s difficult to simulate experiences, such as testing for motion sickness, without actually playing with the real devices. This is especially challenging with the newer mobile platforms, such as Google Cardboard, which incorporate a viewing device that transforms the mobile phone into a VR headset. That experience simply can’t be simulated accurately on a PC, a common testing strategy for other mobile apps. Companies testing mobile VR apps may need to invest in the purchase of dozens or hundreds of different mobile devices to gain an accurate picture of how the application performs for most users.

Hyperconnected Apps

Web-based and consumer apps comprise the bulk of hyperconnected apps, characterized by having deep, often real-time integration with other applications. Instagram and Facebook, Gmail and Google Calendar, Salesforce and their wealth of apps—these are just a few examples of hyperconnectivity. The advent of REST APIs has facilitated far easier and cheaper integration so any company can build a platform of third-party software in ways they couldn’t have imagined five or 10 years ago. Similarly, with the explosion of the app economy, including open source software, it doesn’t make good economic sense to write 100 percent of code in your application any longer. Product value is increasing the result of how developers can patch together different technologies in innovative ways.

Testing considerations: Given the importance of APIs in hyperconnected applications, a primary testing consideration will be ensuring the performance validity of those connection points. It’s imperative for both developers and testers to be aware of API update schedules and to test those updates immediately for any negative impact on the application. Beyond API testing, load and performance testing are also important considerations for hyperconnected applications, which typically involve heavy and/or unpredictable transaction processing. Overall, these types of testing are much more technical in nature than manual UI testing and will require testers to expand their skill set to optimize value.

Internet of Things (IoT)

The interest in (and hype) for the IoT sector rivals the largest IT trends, such as big data. Initial applications have focused on connecting devices, such as home lighting and thermostat systems, which use sensors to stream data to smartphones. Over time, we will see more device-to-device connections such as a thermostat collecting data from a smoke detector to ensure that the house isn’t on fire if the temperature rises dramatically. Products such as Amazon Echo and Google Nest might be at the heart of many new consumer-based IoT applications, but there is also ample potential in sectors such as utilities, health care, industrial equipment and government (a.k.a. smart city initiatives).

Testing considerations: As IoT applications mature, connectivity complexity will grow. IoT applications can involve many components: the hardware of the smart device or product and the software that controls it, along with the user applications that interact with the product. When troubleshooting an issue or vulnerability, a tester must investigate the applications that collect, analyze and display the IoT data, the various network connections across which that data travels, the IoT appliance’s hardware and its software. Hardware testing must incorporate typical scenarios such as what happens to the user experience when a device starts to run low on battery or goes offline. Testers will be most valuable when they have experience in both hardware and software testing; alternatively, an organization can have two teams of testers but they must be in very close contact. IoT apps should also be configured to collect and deliver more alerts and logging data than mobile apps, due to the higher number of components involved. This will make it easier to prevent, troubleshoot and fix problems when they arise.

About the author/Kevin Dunne

Kevin Dunne is VP of Strategy and Business Development at QASymphony.

June 6, 2016
Rep Spotlight: Global Lynx

DevOps Institute: Tell us a little about your organization:

Global Lynx: Global Lynx is a leading and fast-growing IT consulting and training company that assists companies and government agencies improve the competence and skills of their IT organization, enhance the maturity of their IT governance and improve the quality and effectiveness of their IT operations, services and processes.

Since 1996, Global Lynx experts have helped organizations in five different countries, improving—and often transforming—their IT operations through the implementation of effective frameworks for IT governance, ITSM (IT services management), PMO (project management office) and information security.

As an Accredited Training Organization (ATO), Global Lynx also offers a wide variety of IT courseware covering different areas, standards, frameworks and methodologies, and at various levels of expertise.

Global Lynx trainers are experienced consultants, certified in multiple IT disciplines. They have actual firsthand experience in their areas of IT expertise, as well as experience in delivering training programs.

DOI: What other topics do you teach or consult on?

Global Lynx: IT service management, IT corporate governance, IT audit, information security, cyber resilience, IT risk management, cloud computing, project management, SCRUM, business continuity, process design and implementation, and enterprise value creation.

DOI: What type of interest in DevOps are you seeing in your region?

Global Lynx: Companies are interested in obtaining a common understanding of DevOps concepts and best practices, and they are focusing on deploying these practices organization-wide.

DOI: How do you think that DevOps contributes to the business’s value stream?

Global Lynx: The digital disruption all industries are experiencing, has created the need for IT to be embedded in every single business unit. Solid DevOps practices will help IT organizations deliver higher value to their customers, as value is delivered through operations, but it is defined and enabled in the development stages. Value should be managed not only in operations, but rather from the early stages of the service life cycle. A mature IT organization cannot have a poor collaboration and communication culture; without this, value creation will be limited to technical value instead of real business value.

DOI: What topic area in DevOps excites you the most?

Global Lynx: How DevOps interfaces other frameworks and how all of them can work together toward creating value to the customer.

DOI: Why should enterprises and individuals consider formal DevOps training?

Global Lynx: DevOps is all about people, and it is enabled by people. If a person is not committed, that person will do little to support the DevOps initiative. People need to go through formal DevOps training to learn what DevOps is, and how their role impacts the initiative and how they contribute to value creation. Certification is a plus, as it gives people a personal benefit. People will naturally react positively to something they own, because they will believe in it.

June 3, 2016
DevOps: Shift Left to Reduce Failure

DevOps is all about increasing the feedback loop from idea to customer and back again. Tremendous gains have been achieved in automation and tools to drastically reduce the amount of manual labor involved in progressing down the release pipeline. But mission-critical applications in a highly competitive market cannot afford to go down. Complex applications, environments and infrastructure increase risk, which can cause failure.

The failure rate of production deployments is still too large. Studies show that the average cost of a production outage is roughly $5,000 per minute, while the average cost of a critical application failure per hour is $500,000 to $1 million.

Why so much failure? All too often we’re still seeing a lack of consistency across the release pipeline. Many times the provisioning and deployment processes are very different at the opposite ends of the pipeline. But by shifting left the operations concerns, you can achieve much more success in production.

Understanding How to Shift Left

The term “shift left” refers to a practice in software development in which teams focus on quality, work on problem prevention instead of detection, and begin testing earlier than ever before. The goal is to increase quality, shorten long test cycles and reduce the possibility of unpleasant surprises at the end of the development cycle—or, worse, in production.

Shifting left requires two key DevOps practices: continuous testing and continuous deployment. Continuous testing involves automating tests and running those tests as early and often as possible, along with service virtualization to mimic unavailable systems. Continuous deployment automates the provisioning and deployment of new builds, enabling continuous testing to happen quickly and efficiently.

The first and most obvious way to shift left operations is to work side by side with development in creating the deployment and testing processes. Failures observed in production often are not seen earlier in the life cycle. Many times these failures can be attributed directly to differences in deployment procedures. Development may create its own deployment procedures that are very different from those used by operations for production. Sometimes production procedures are much more manual and may even use different tooling. Operations and development need to take ownership in building standard deployment procedures. The deployment process is then practiced potentially hundreds of times in test environments before reaching production. You then have much more confidence that the production deployment will be successful.

Another way to reduce the failure rate is to make all environments in the pipeline look as much like production as possible. This is almost impossible using traditional provisioning processes. Production environments usually are much heavier and detailed than are needed by development. But by using cloud and pattern capabilities, you can get much closer.

The ability to use patterns to define consistent environments eliminates the failures that occur simply by configuration inconsistencies. This again requires operations and development to work together in creating the provisioning process so developers create their test environments the same way they are created in production. Using IBM UrbanCode as an example, this can be done by connecting UrbanCode Deploy to an automated self-service provisioning system such as OpenStack HEAT or IBM Cloud Orchestrator connected to OpenStack.

These standard patterns can be used to create environments for all stages of the pipeline. And by using cloud capabilities you can deprovision these environments as fast as you can create them. This also allows the enterprise to have confidence in their environment patterns. They are tested on a daily basis and, therefore, operations can feel confident that testing is done on production-like environments.

No one wants to experience production failures—and it is in everyone’s best interest to do all they can to prevent them. At the root of DevOps is the removal of those silos between development and operations. By applying these shift left operations principles you are well on your way to reducing your failure rate.

The ingredients to make shift left are real and available: automated testing and deployment tools, service virtualization technology, agile practices and cloud environments. The main obstacle that remains is the mindset of delivery organizations. Learn more from the newly updated Application Deployment and Release for Dummies ebook to find out more.

About the author / Dr. Darrell R. Schrag

Dr. Darrell R. Schrag (@devopsdrs) is an experienced software lifecycle consultant specializing in the IBM cloud solution, helping customers establish their cloud strategy across the enterprise. He’s focused on implementing continuous delivery of software applications through the delivery pipeline incorporating cloud and provisioning solutions. He’s experienced in helping clients transition to “born on the cloud” applications utilizing microservices to take advantage of a flexible and nimble cloud platform.

June 2, 2016
Five Harsh Truths About DevOps

DevOps can provide tremendous productivity improvements, but it’s not a panacea. As much as we’d want it to be the solution for all of our software development problems, here are five truths you should consider.

1. DevOps may lead to juggling job roles and coming out of your comfort zone

With DevOps, the development team is responsible for writing the automated scripts that deploy the application. That used to be manual work done by someone in operations. Just as in manufacturing, automation will eliminate jobs. Typically, that system administrator can be retrained to work in development writing those deployment scripts, but programming is a different skill from restoring databases. If you can’t adapt, it’s time to update that resume.

2. Not everything should be automated

Yes, DevOps can be made to work on any platform, including the mainframe. No, it’s not confined to projects using agile. You don’t have to use Ruby or PHP; it’ll work for Fortran applications too. But be realistic. Transforming an application to use DevOps is expensive. You should not invest in something that is slated for sunset, or only has one release per year to fix some minor bugs. Legacy systems are considered legacy for a reason. Focus on the top 20 percent of your portfolio instead.

3. Developers will need to get their hands dirty

Some developers like to do one thing, and one thing only: write code. Grudgingly, they’ll test; they’ll attend team meetings if they have to; and, if tortured, they’ll write documentation. But forget about getting them to create the installation scripts.

That mindset is not going to fly in a DevOps world. Developers need to think about how the application will run as a nonfunctional requirement, and treat it with the same level of importance as security, performance and data privacy. Unless they feel ownership of the installation process, monitoring the environment and collecting end-user feedback, you have not really implemented DevOps.

4. Operations no longer can be ticket-driven

Usually, the operations team doesn’t get involved until someone from the development side opens a ticket for deployment. That’s too late for any kind of meaningful integration. The answer is not opening a ticket three months earlier; tickets are meant to be assigned, worked and closed within a short period of time. The type of collaboration needed between development and operations is far more complicated, and should be treated like it’s a project. That’s really difficult for most operations organizations. It’s not part of their culture, and they’re not staffed for that.

5. Your process is really, really bad

As soon as you start automating your software delivery process, you’ll find out exactly how inefficient it really is: duplicate reviews, inconsistent forms, competing standards … When you take away the people layer, you can’t hide the crazy anymore. You don’t want to take what you have today and force it into an automation tool. You will need to standardize before you optimize, and optimize before you automate. That means a lot of different towers will need to cooperate—something that won’t happen unless there is an outside party driving the cooperation with a big stick.

To learn more, check out the hangout with industry experts: What will DevOps look like in three to five years?

What aspect of DevOps do you think people are uncomfortable to talk about? Leave a comment below or contact me @baspluim

About the author / Jan S (Bas) Pluim

Bas Pluim is a Cloud/ DevOps solution architect in IBM’s innovation practice. He works with clients on infrastructure solutions, process re-engineering, automation tools and transforming the overall software delivery process. Bas is also a member of the IT Specialist certification board, a gaming enthusiast and an advocate of social media tools

May 24, 2016
Simulation: The ‘Aha’ Moment for DevOps Adoption

Every IT transformation requires that people, process and technology align and work together to achieve success. As organizations begin to appreciate the benefits of a DevOps approach and look to change to a DevOps model of software development and release, there will be significant pressure on people, process and technology to support that change properly.

The technology and process changes required to enable DevOps to work efficiently shouldn’t be underestimated. Considerable time and investment is required in embracing the automation technologies that support a proper DevOps environment, and in developing the processes that make best use of that technology.

But DevOps cannot work unless your people are ready to change. Development teams and IT operations—who traditionally have worked in silos—must work together, integrate seamlessly and understand not only their roles and responsibilities within the new environment but also the roles and responsibilities of those around them.

And therefore, like every change, the real key to success is your people.

Creating Successful Change

The benefits of taking a DevOps approach are numerous: By moving toward more frequent delivery with reduced elements of change, you lower risk and increase system stability. Although automation is costly to implement, it allows teams to work far more efficiently, increases reuse, reduces errors and brings development teams closer to the customer. New functionality released continually and rapidly can be validated in the market, feedback can be received, lessons can be learned and improvements implemented quickly.

But in making such a radical cultural shift, how do you ensure you change the mindset of people who have been used to working in a certain way? How do you provide your people with the helicopter view of what that future state will be, instill in them your fervor for change and provide them with the understanding and motivation necessary to embrace new ways of working? How do you ensure everyone is rowing in the same direction? Because without that, your change—already difficult and challenging—will become impossible.

The Key to Change

The key to any successful change is communicating your vision to your people. But providing your staff with a clear vision of what that future state could be is enormously difficult. You can outline the benefits of change, explain to them what good will look like, tell them what is in it for them, and all of these are hugely important.

But there is no substitute for allowing people to actually feel what your future state will be like.

Nothing compares to parachuting them into a situation where they can work through the changes required in a risk-free environment, experience the pitfalls and live the successes. As you move them to a fully functioning and productive DevOps environment, you will accelerate buy-in from your team rapidly, and give them a much more profound understanding of your vision and future state.

The Power of Simulation

Simulation training is one of the most effective tools to explain complex concepts and operating models quickly and convincingly. A presentation on DevOps—or almost any other topic—is not a productive method of showing someone the difference it can make to their work or their business. It’s the difference between reading a script and performing a play. More and more, companies are using simulation training as a shortcut to inform, educate and convince their teams of the value of large-scale organizational change—and DevOps is a prime example.

One of the key benefits of the simulation model is that people learn together. Your team learns at the same pace, working toward the same goals—and, as a result, they collectively show each other the value of change. With a traditional change program you need each employee to go on his or her own journey to recognize and adopt your vision. With a group simulation you take everyone present down the road toward a collective “aha” moment. Once that moment has happened you have an instant group of advocates who can go out to the business together and begin to effect change on a much more fundamental level.

Simulation Brings Agility to Adoption

Providing a simulated environment in which to train is not new; it has been used extensively and successfully by the military for decades. Commercial pilots train on simulators to provide them with as close to a real-world experience as possible of some of the life and death decisions they may need to make in an emergency. They understand the power of experiential learning.

Simulating a DevOps model brings that power of experiential learning to your business, allowing you to immerse your people in a concentrated and deeply focused environment where they face the same challenges as they will in the real world.

In one short morning they get to experience building a culture of DevOps themselves, making mistakes, understanding them and learning from them. It demonstrates the business value and positive impact of a DevOps approach in only a few hours, and can accelerate the adoption of DevOps across the enterprise, successfully turning DevOps opponents into advocates.

In a world where the quality of your software can make or break your organization, it is critical to create an environment where developers and operations are not only aligned and more efficient, but also empowered and able to concentrate on developing and releasing products that add the most value to the business.

Rome wasn’t built in a day, and you can’t effect convincing organizational change in a single morning. However, by immersing your team in a simulation, you can take a giant step forward and create a team of advocates who will go out and sell your vision for you.

About the Author/Andrew Macintosh

Andrew Macintosh is a Creative Solutions Director for G2G3. He works with clients across the globe, helping to understand requirements and craft technology based solutions to engage staff and customers, internally and externally. Prior to joining G2G3 Andrew ran a production company and worked within the TV industry for 12 years.

May 23, 2016
Best Practices for Cloud Deployment

When it comes to deploying apps in the cloud, the conventional wisdom is that DevOps is not required if you’re a small or midsized company. The cloud is designed to enable virtually anyone to set up the infrastructure they need, quickly and easily, without a lot of experience in the intricacies of managing data center operations or hardware. But then, by the time the company realizes it needs DevOps, it’s almost too late—the cloud infrastructure has become complex, costs have exceeded expectations and precious time is being wasted.

To ensure you’re able to optimize cloud, or hybrid cloud, deployments—and avoid many of the problems that other companies have experienced—there are a number of best practices you must employ within your company.

Best Practice No. 1: Realize You Need DevOps from the Start

When you manage your own hardware, you know exactly what the deployment costs are and what resources are available, and have a clear understanding of how they are interrelated. The abstraction of the cloud makes the initial setup a snap. But typically there is no formal structure involved: Individual developers can initiate new instances whenever they need them, without considering the bigger picture of the resources already in use, how they’re used or what is being planned by the organization.

Spinning up unnecessary cloud resources not only costs a company more in the long run, it also leads to a cloud sprawl that requires time-consuming, manual processes to maintain. Think about the challenges your company would face if it had thousands of machines created by different processes but you didn’t know who created them, what they were being used for or even if they were still needed.

By employing DevOps from the start, you will be able to balance the needs of developers with the availability of resources in the cloud to ensure expenses do not run out of control and you understand exactly how the cloud infrastructure is being used now and into the future.

Best Practice No. 2: Have a Process and Purpose

As you create your cloud infrastructure, you need to have a clearly defined purpose, as well as a process in place for deployment and ongoing management. You will need to keep track of what resources are being used and their designated purposes. Some cloud vendors, such as AWS, offer tagging capabilities that help you keep track of what services each machine was created for and whether they are being used for production, backup, load balancing or testing.

Regardless of whether you use tagging capabilities or maintain a separate database of cloud resources, knowing what you have purchased and how it’s being used will provide needed visibility, ease of management and greater control of costs.

Best Practice No. 3: Leverage Automation

Automation is important—both in the cloud and on premises—to streamline routine practices, make sure they’re applied consistently and eliminate potential errors that are common with manual processes.

When deploying on multiple clouds or in a hybrid environment, it is important to understand that tags used for one cloud provider won’t work on another. The process is typically broken into three steps: inventory creation, system preparation and automatic deployment. Many cloud systems allow you to create a dynamic inventory directly from the servers, eliminating the need to create or maintain it manually. However, deployment over multiple clouds require an abstraction of this inventory; it is common to create a static inventory in a unified format from the various dynamic inventories.

Best Practice No. 4: Design the Network with Security in Mind

Poorly designed networks are almost impossible to secure. Problems often arise when companies allow their networks to grow organically rather than being planned out in advance. A number of companies have employed the best practice of segregating the services network and the management network. The services network includes all the components required to provide services to your customers and users, while the management network is comprised of what you need internally to manage the network. Separating these networks provides greater assurance that unauthorized users cannot gain access to your systems via the Internet.

Another part of security is key management. Depending on the cloud provider, keys can be widely available or have a root password that is open to the world. In fact, many hackers routinely scan Github for keys developers accidentally check in. With having to manage so many keys, you may struggle to ensure that they’re not exposed. DevOps plays an important role in keeping the keys locked away, then providing them to a select group of individuals who can use them only in production.

Best Practice No. 5: Be Strategic About Monitoring

When you’re deploying hardware on-premises, it’s a common practice to define in advance what to monitor. But monitoring in the cloud is quite different, with basic defaults that produce vast quantities of data—much of which may not be relevant to your organization.

Taking a cue from how you handle monitoring on-prem, you’ll want to design cloud monitoring to fit your company’s unique needs and filter out the information that isn’t pertinent to your network or operations.

Best Practices Go a Long Way

Keeping in mind these best practices and employing a DevOps model from the start will enable your company to get the most benefits from its cloud deployment regardless of its size, and avoid the costly and time-consuming challenges that arise without proper advanced planning and a strong focus on network design and processes.

About the Author/Roger Fulton

Roger Fulton is Iron.io’s director of Infrastructure and Operations. His background includes broad experience in software architecture and operational planning. He manages international teams to deliver highly available products for end users and highly performing in-house infrastructure. Prior to joining Iron.io, Roger served as head of application and infrastructure engineering at Kaybus. He has also held technical leadership roles at JRV Consulting Group, Cybrata, Invisible IT and Clarus Systems. Roger holds a Masters from the Queens University of Belfast, having graduated with highest honors.

May 20, 2016
DevOps is ITSM Best Practice!
What boggles the mind is that opponents of DevOps use risk as an excuse why DevOps would not work in their environments and why using the “traditional ITSM” approach is better and safer.

When I start asking them about their transition practices, specifically the alignment between transition, change, test and release models, I soon find that these models are either very skimpy or, most of the time, non-existent.

So here are the facts: You don’t want to do DevOps because you don’t want to do what ITSM best practice dictates!

ITSM best practice recommends building and aligning change, test, release, deployment and transition models that clearly define transition/change boundaries, practices, artifacts, acceptance criteria, roles, responsibilities and authorities, making transition practices repeatable, less risky and more reliable.

Is this not exactly what you need to do in DevOps automation? If you have not built the models and made sure they are tried and tested, you can’t automate them—and if you have built these models and made sure they are tried and tested (repeatable), then why not automate them? It’s a no-brainer.

The reality is that by using DevOps practices, organizations have far better control and manage risk far better than what opponents and detractors of DevOps have in their non-DevOps environments.

This may not be best practice, but we have for years recommended that during a post-incident review the following questions should be added to the agenda:
- Will we do this again? If so,
- Will we do it in the same way?
- Can we define an implementation approach based on the change just completed and the lessons learned, and can we reuse this approach safely in future (build change, release and test models)?
- If we can,
  - Build the models
  - Define this type of change as a standard change
Some say that this is not best practice, as “standard changes” are low risk. This, in fact, is not true!

ITIL® defines a standard change as follows (ST 4.2.4.7): “A standard change is a change to a service or other CI for which the approach is pre-authorized by change management, and this approach follows an accepted and established procedure … Every standard change should have a change model that defines the steps to follow … Authorization for each occurrence will be granted by a delegated authority … The crucial elements of a standard change are defined triggers, tasks are well-known, documented and proven, authority is given in advance … The risk is usually low and always well-understood.”

We have for years argued that standard changes are ideal candidates for automation. By extending the post implementation reviews, you identified safe candidates for DevOps automation!

About the Author/ Johann Botha

Johann Botha is the CEO of getITright, a DevOps Institute Registered Education Provider that will run its first African DevOps course May 23 in Johannesburg. Visit www.get-it-right.com for more info.
May 19, 2016