devopsy.kinsta.cloud

Tag: infrastructure

Q&A: BDO’s Coffman on Change Management, Security and DevOps, Part 2

As we covered in part one, DevOps’ best asset and biggest risk factor may be one and the same: swift and precious change. In part two, we continue our discussion of the challenges and solutions with Deena Coffman, managing director of BDO Consulting’s Technology Advisory Services practice.

David Geer: What specific tools and technologies can help DevOps teams to address change management in these ways?

Coffman: There are a variety of tools and technologies to address some of the inefficiencies in change management, allowing DevOps teams to automate most of the process. For example, teams can leverage change management software to build pre-authorization processes and workflows to speed up change management approvals. On the security side, infrastructure monitoring tools will alert an organization when a discrepancy is discovered on the network, providing application visibility to the users and monitoring for unauthorized changes. DevOps teams should also consider using a collaboration platform like Slack to improve communication via virtual meeting places.

Geer: What will these tools accomplish and how should teams be using them?

Coffman: These tools are only useful if used properly. Deployments that require change management approval can go through the automated workflows. If a change requires approval, developers can use Slack or any other collaboration platform to contact the required party and explain the reasoning behind the modification. DevOps teams must also take the time to identify and automate as many “standard” changes as possible to reduce the reliance on change control meetings to speed up their deployments.

Additionally, DevOps teams need to consider using an infrastructure monitoring tool to ensure all changes to the production environment are known and authorized. If a change finds its way to production without getting the appropriate authorization, the monitoring tools can detect it and report it to the team so they can rectify the issue.

Geer: What kinds of things do DevOps teams need to do to address security to the satisfaction of the business?

Coffman: The development team and security do not need to be at odds. By working in unison, both sides can reach their objectives.

The InfoSec team would help the development team by making efforts to reduce the latency of security projects. The development team would help not only the InfoSec team—but potentially the entire organization—by preventing an expensive and embarrassing security incident by diligently supporting tools that automate security checks.

Additionally, the build process needs to run unit testing, integration testing, functional testing, regression testing and information security testing before the code reaches QA. Security testing is often insufficient or not performed at all. DevOps teams need to understand that security testing performs an important function of catching issues early so as to avoid expensive, embarrassing issues downstream.

Geer: What specific tools and technologies can help DevOps teams to address security in these ways?

Coffman: Several tools are available to help DevOps teams address security in many different capacities, including setting up continuous integration/continuous delivery processes, automating server configuration, automating UI testing and functional security tests, testing the security requirements of applications and automating the vulnerability scan of applications and infrastructure.

Geer: What will these tools accomplish and how should teams be using them?

Coffman: DevOps teams should integrate these tools as part of their continuous delivery process. As soon as a developer checks his code in, the continuous delivery system should run the functional security tests, non-functional security tests and the security scan to ensure that the developer did not introduce a security vulnerability to the application and the infrastructure. These tools are only as powerful as the test scenarios they run. Therefore, teams should write exhaustive test cases to ensure the security of the application.

Geer: How can teams do all these things and still maintain all the benefits and expectations that people have of DevOps itself?

Coffman: By deliberately working toward improved collaboration and communication, teams can take advantage of the integration and efficiency benefits of a DevOps structure without sacrificing security or quality. Technical knowledge is important, without a doubt. To be exceptional, though, teams need equally strong teamwork and communication skills to actively support all important functions in the organization.

— David Geer

September 16, 2016
The devopsy.kinsta.cloud Containerization and Microservices Survival Guide

Containerization and microservices seemed to have leaped out of nowhere and smack into the center of the enterprise IT scene. But neither leaped from nowhere. Both containerization and microservices have been part of the fabric of enterprise tech for some time—within Linux for containers and service-oriented architecture for microservices.

Largely, thanks to containerization, both now are moving quickly to become central components of enterprise tech. Containers in recent years—and especially in recent months—have moved from tools used in development environments to production. And the ability to manage containers as discrete services is enabling enterprises to be able to respond quickly and be agile to technology demands.

According to a recent survey from app performance vendor NGINX, of roughly 1,800 IT professionals, while container and microservices software adoption is limited it’s use is accelerating. The survey found that only 20 percent of respondents said they are using containers in production, while about one-third are doing the same for microservices.

That survey, not surprisingly, indicated that microservices and container use will continue to accelerate, as roughly two-thirds of respondents said that they are currently evaluating containers and 70 percent microservices.

Microservices are workloads that perform a single task and they are not dependent on the infrastructure or other applications for their ability to complete their designated task or “service.” Microservices are very effective at providing enterprises the ability to rapidly build software that solves business problems. They also make it possible for development teams to scale their efforts and build a more resilient architecture.

With all of that in mind, and considering the nature of the inflection point most enterprises find themselves in now, we’ve assembled this microservices and containerization survival guide. The guide consists of some of the most important storage on microservices and container management that we’ve ran in the past year.

DevOps Teams: Containers Will Help You Become Future Ready

According to The State of Containers 2015 Docker Adoption Survey, more than 70 percent of respondents are either using Docker or evaluating for future use. Given the overwhelming popularity of containers, this post provides three trends that DevOps teams must be prepared for.

7 Web Interfaces for Container Management and Orchestration

Managing containers used to be a command-line affair. But a rich and growing ecosystem of web-based interfaces for containers has now emerged. This post provides an overview of the different web UIs available for container management and orchestration.

‘Containers-as-a-Service’ Is a Hot Trend

Containers are still sort of the new kid on the IT block, but already containers-as-a-service is emerging as a thing. Here’s what you need to know.

A Closer Look at Container Monitoring

Enterprises have to ensure that all of their microservices perform well and provide their services as designed. Beyond that, how much do they really need to know about what’s going on inside their containers? The answer to this question varies. In this post Gerald Haydtner provides an overview for container-monitoring options.

Containers: Not One to Rule Them All

When it comes to the container platform ecosystem, not all container platforms are created equal. This post will help you sort through the options.

Building Microservices: A Few Considerations

An experienced practitioner details the top five design considerations when building microservices.

5 Docker Best Practices You Should Follow

Support for Docker has been integrated into many products and platforms and a lot of organizations are either already using Docker containers or trying to understand how to do so themselves. Our Tony Bradley provides the Docker best practices one needs to know to succeed.

How to Choose a Cloud Platform for Containers

Containerization has broadened from one or two vendors to a broader, more container-agnostic world and a drive to better scalability, redundancy, interoperability and security. Amazon, Google and Microsoft each have their own unique approach to addressing these cloud container concerns as they battle each other for supremacy. Here’s a look at how to evaluate each.

Container Security: Why Bother?

Are containers secure? Probably not. But knowing each approach’s strengths and risks—and available options—could help ease adoption.

Container Security Challenges: Are Container Scanners Enough?

How secure are containers? Not very, according to open source company Red Hat, which has published a blog post blasting the container ecosystem for lacking good security processes. Here’s a synopsis of what Red Hat has to say about container security, and some additional perspective.

For Container Security, Automation Is Key

Regardless of the IT infrastructure element in question, if it connects to a network—even through proxies or human intermediaries—eventually someone will find a security flaw and exploit it. Compatibility issues with new applications or infrastructure elements will emerge. Because of these reasons, all IT infrastructure elements need to be managed, without exception.

Containers and Security Q&A: Putting a Lid on Risk

How do containers affect security? And how can IT teams do everything they need to do in order to ensure the containers in use are as secure as they reasonably can be?

— George V. Hulme

September 15, 2016
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.

August 10, 2016
Can DevOps Be Applied to Production Networks?
The key goal of DevOps is to bring development and operations together, bound by a common set of practices. For this to become reality, developers need to think more like the operations team—focusing on stability and reliability—while operators need to think more like developers—focusing on agility and speed. But how widely can this be applied?

We say regularly the goal of application development is to deploy new features into production continuously—daily, weekly or monthly, if possible. But what about the production infrastructure itself? Can we apply DevOps practices to making changes to the production infrastructure on which these applications run?

Recently, I met with customers who want to implement DevOps practices to how they manage their operational network, applying continuous deployment to the production network. For example, they would like to design, test and then deploy new network services such as load balancing and firewalls into production immediately to enable new applications and services—actions that currently could take weeks or months. Is this kind of continuous deployment to be expected, or is it pushing DevOps too far?

Let’s look at how key concepts of DevOps might be applied to adding network services to a production enterprise network:
1. Virtualize services: To enable rapid deployment of applications, it was first critical that they be enabled with virtualization and in the future, with containers to make them portable. We would need to apply this same approach to production network infrastructure if we expect to enable rapid deployment of new infrastructure. Unfortunately, there is no standard way to make physical network equipment portable. Of course, shifting heavily to software-defined networking (SDN) enables virtualization for free, but it doesn’t make even virtual network equipment “standard.” In the world of networking, there are a number of “standard” interfaces and modeling languages: SNMP, NetConf, Yang and TOSCA (though not originally designed for networking), to name a few. Using one of these standard interfaces, in combination with virtualization, potentially could enable the agility required for continuous deployment of network services.
2. Automate: DevOps success depends on automating the entire process of development, test and deployment so the process can be continuous. The same level of automation would need to be provided throughout the process of designing, testing and deploying new network services onto production networks. Network testing is very similar to other types of hardware and software testing so most test automation frameworks can be applied. However, network testing requires automation of the environment setup, and it also requires traffic generation to test with realistic network conditions.
3. Continuously deploy: While this is still a dream for many companies attempting to achieve DevOps nirvana, a key requirement for using DevOps for production network configuration is to be able to deploy new services continuously into a live production network. Most of the configuration management tools available today are good at configuring servers and software, but are more immature when it comes to configuring networks, which are far more complex and inter-dependent than a single server. A tool would be required that allows the configuration of the tested network to be deployed automatically in exactly the same way within a production network.
4. Monitor Operation: A good DevOps practice monitors applications in production and uses that information in planning new services. While it would seem that network monitoring is quite mature, an open question is whether that data is useful in planning future network services for improved operation.
Sandboxes for Network DevOps

Sandboxes are tools for defining and testing infrastructure configurations (physical, virtual and application). A good sandbox allows users to model any infrastructure, including any type of network infrastructure. This model also can serve as a way to implement “virtual services.” Models can be created in Yang or TOSCA, and under the covers these models can automate access to network infrastructure using CLIs, SNMP and/or NetConf where appropriate. This allows network services to be defined and tested using a high-level model, rather than the low-level interfaces.

Sandboxes also address automation by providing a context for automating not just individual network components but also entire configurations and connectivity that are required for a “network service.” In addition, automation can encompass traffic generators and test tools as part of the testing process.

Sandboxes also are designed to set up and tear down a network service automatically so they can be used for continuous deployment of new services. The same automation used to create the sandbox for a network service also can be used to deploy it into production.

Finally, monitoring used in production also can be performed in the Sandbox to compare performance between testing environments and production so future services can be improved.

While applying DevOps to production infrastructure and services is challenging and immature, in principle it can provide significant improvements in the speed of deployment of new network services—and the applications that depend on those services.

About the Author / Joan Wrabetz

Joan Wrabetz is the Chief Technology Officer for Quali. Most recently, she was the vice president and Chief Technology Officer for the Emerging Product Division of EMC. Ms. Wrabetz holds an MBA from the University of California, Berkeley, an MSEE from Stanford University, and BSEE from Yale University. She has taught as an adjunct faculty member at the University of St. Thomas, St. Mary’s University, and at the Carlson School of Business at the University of Minnesota. She holds patents in load balancing, distributed systems and machine learning classification and analytics.
July 15, 2016
What ‘Star Wars’ Can Teach Us About DevOps Automation
Perhaps no movie has ever received the same level of hype as “Star Wars: The Force Awakens.” Longtime fans yearned for the latest episode of the sprawling saga to bring back some of the magic of the original movies, while paving the way for the next generation of the “Star Wars” universe.

In this way, the current state of “Star Wars” provides a useful way for understanding the infrastructure evolution situation that many IT organizations now find themselves in.

‘Star Wars’ and DevOps Automation

Just as “Star Wars” has lots of previous characters and concepts—from Han Solo to the Force itself—to weave into its new properties, DevOps-minded teams have their own legacy infrastructure (admittedly, not as glamorous or nearly as profitable as the 1970s vintage “Star Wars” canon) to bring into a future defined by virtualization, automation and cloud orchestration. This modernization effort can go several ways depending on what approach is taken:
- Organizations may quickly run into difficulties if they treat their DevOps initiatives as simply a new type of silo, one that is focused intensely on virtual and cloud assets without ample attention paid to legacy and physical infrastructure. You could say that a similar tack was taken with the first Death Star: Despite all of the focus on its planet-destroying weaponry and enormous tractor beam (which hauled in the Millennium Falcon), the space station’s designers neglected its basic heating infrastructure, eventually settling on a small exhaust port that was vulnerable to torpedo attack (and, indeed, was destroyed in that exact way).
- On the other end of the spectrum, creating a culture of collaboration supported by highly capable technical tools can ensure that DevOps innovation takes hold and facilitates business agility. Think of this ideal as being similar to the relationship between R2-D2 and Luke Skywalker when the latter was piloting his X-Wing Fighter. There was not only a good understanding between the two of them, but also the powerful automation capabilities provided by R2’s advanced circuitry.
The new Star Wars movie provides an occasion to see how old and new infrastructure, such as that inside the Millennium Falcon, can work together.

Overall, we can see here both a “dark side” and “light side” approach to DevOps transformation. An old joke about the Force is that it is a lot like duct tape: it has a dark side and a light side and it holds everything together. Something similar could be said about the variety of infrastructure types that support critical business applications. They can cause a lot of problems (e.g., they probably can’t match the credit card-swipe convenience of Amazon Web Services), they can provide some key advantages (e.g., by being easy to control and secure on-premises) and ultimately they are essential cogs for supporting a wide range of applications, especially within bimodal IT setups.

Why the Millennium Falcon Would Have Benefited from a Better Self-Service Portal

Since we are on the subject on supporting and holding things together, we should talk a little about the Millennium Falcon, a ship that always seemed to be on the verge of breaking down in the original films. Its hyperdrive for making the leap to lightspeed was spotty at best, and it took its fair share of bruises. Keeping it in working order and out of the clutches of the Empire was a full-time job for Han and crew.

Part of the problem was the Falcon was this weird mix of old and new technologies. It could travel at warp speed, fire lasers and make the Kessel Run in less than 12 parsecs. But it also required human pilots and gunners; plus, it was accurately labeled a “bucket of bolts” by Princess Leia Organa during a critical escape sequence.

Maybe the Millennium Falcon would have run a lot more smoothly if it had a self-service portal that helped keep tabs on what was going on around its decks. Are the ship’s countless modifications playing nice with its older components? Is there a technical problem hidden in one of its smuggling holds? Is the holographic Dejarik table from Episode IV eating up too many resources? Having a centralized automation platform would have helped with these issues of accountability, visibility and IT governance.

One could say that the Millennium Falcon was already a rough approximation of environment-as-a-service (EaaS), since it passed muster in automating a lot of heterogeneous infrastructures implemented and modified by its various owners. But it could have gone further in bridging the gap, just as many IT organizations can take additional steps to ensure DevOps automation success by working with software such as CloudShell.

The takeaway: “Star Wars: The Force Awakens” provides an occasion to do more than sit back and enjoy the lightsaber fights —it’s also a moment to see how old and new infrastructure, such as that inside the Millennium Falcon, can work together. With an EaaS and self-service automation solution, IT organizations can bring their legacy, physical, virtual and cloud assets together into a more agile combination.

About the Author / Hans Ashlock

Hans Ashlock joined Quali in 2013 and heads Quali’s worldwide technical marketing. Hans has more than 15 years of software engineering, product management, marketing and sales experience in automation software solutions addressing, cloud, networking, telcom, data center, federal, and semiconductor industries. Before Quali, Hans was a founding member of a global engineering services company, developing products and services for enabling adoption of automation technologies. Though he only holds one patent, he’s glad he didn’t have to pay for it. An engineer at heart, Hans is passionate about the transformation to software-defined everything and its impact on business and technology. Connect with him on LinkedIn, Twitter, and SlideShare, or at www.qualisystems.com.
July 14, 2016
How to Fail at Test Automation
Let me start by admitting that I am not a test automation expert. I have done some work with test automation and have supervised teams who practiced it, but when it comes to the intricacies of it, I have to call a friend. It is from such friends that I have learned why so many test automation efforts fail. Talking to people about test automation validates my impression that this is the DevOps-related practice that people most often fail at.

Let me share the four reasons why test automation fails, in the hope that it will help you avoid these mistakes in your test automation efforts.

Before I go into the four reasons, allow me one more thought: Test automation is actually a bad choice of word. You are not automating testing, you automate quality assessments. What do I mean by that? It is a mistake to think of test automation as automating what you otherwise would do manually. You are finding ways to assess the quality of your product in automated ways and you will execute it way more often than you would do manual testing. This conceptual difference explains to a large degree the four reasons for test automation failure below.

Reason 1: Underestimating the Impact on Infrastructure and the Ecosystem

There is a physical limit of how much pressure a number of manual testers can put on your systems. Automation will put very different stress on your system. What you otherwise do once a week manually you might now do 100 times a day with automation. And into the mix an integrated environment, which means external systems need to respond that frequently, too. So you really have to consider two different aspects: Can your infrastructure in your environments support 100 times the volume it currently supports, and are your external systems set up to support this volume? Of course, you can always choose to reduce the stress on external systems by limiting the real-time interactions and stub out a certain percentage of transactions or use virtual services.

Reason 2: Underestimate the Data Hunger

Very often test automation is used in the same system where manual testing takes place. Test automation is data-hungry, as it needs data for each run of test execution and, remember, this is much more frequent than manual testing. This means you cannot easily refresh all test data whenever you want to run test automation and have to wait until manual testing reaches a logical refresh point. This obviously is not good enough; instead, you need to be able to run your test automation at any time. There are a few different strategies you can use (and you will likely use a combination):
- Finish the test in the same state of data that you started with;
- Create the data as part of the test execution;
- Identify a partial set of data across all involved applications that you can safely replace each time; or
- Leverage a large base of data sets to feed into your automation to last until the next logical refresh point.
Reason 3: Not Thinking About the System

Test automation often is an orchestration exercise as the overall business process in test flows across many different applications. If you require manual steps in multiple systems, then your automation will depend on orchestrating all those. By just building automation for one system you might get stuck if your test automation solution is not able to be orchestrated across different solutions. Also, some walled-garden test automation tools might not play well together, so think about your overall system of applications and the business processes first before heavily investing in one specific solution for one application.

Reason 4: Not Integrating it into the Software Development Life Cycle

Test automation is not a separate task; to be successful it needs to be part of your development efforts. From the people I have spoken to there is general agreement that a separate test automation team usually doesn’t work for several reasons:
- They are “too far away” from the application teams to influence “ability to automate testing,” which you want to build into your architecture to be able to test the services below the user interface;
- Tests often are not integrated in the continuous delivery pipeline, which means key performance constraints are not considered (tests should be really fast to run with each deployment);
- Tests often are not executed often enough, which means they become more brittle and less reliable. Tests need to be treated at the same level as code and should be treated with the same severity. This is much easier when the team has to run them to claim success for any new feature and is much harder to do when it is a separate team who does the automation. It also will take much longer to understand where the problem lies.
Of course, absence of failure does not mean success. But at least I was able to share the common mistakes I have seen and, as they say, “Learning from others’ mistakes is cheaper.” Perhaps these thoughts can help you avoid some mistakes in your test automation journey. I do have some positive guidance on test automation, too, but will leave this for another post.

And in the case you found your own ways of failing, please share it in the comments to help others avoid those in the future. Failures are part of life and even more so part of DevOps life (trust me, I have some scars to show). We should learn to share those and not just the rosy “conference-ready” side of our stories.

Test automation is for me the practice that requires more attention and more focus. Between some open-source solutions and very expensive proprietary solutions, I am not convinced we in the IT industry have mastered it.

One bonus thought: If you cannot automate testing, automate the recording of your testing.

If you cannot automate testing, find a way to record the screen with each test by default. Once you identify a defect you can use the recording to provide much richer context and make it a lot easier to find the problem and solve it. Verbal descriptions of error are very often lacking and don’t provide all the context of what was done. I keep being surprised how long triage takes because of the lack of context and detail in the defect description. There is really no excuse for not doing this. Record first, discard if successful, attach it to the defect record if you find a problem.
July 6, 2016
Echidna Takes DevOps to E-Commerce Site Creation

The Echidna e-commerce firm installs and evolves e-commerce platforms, providing ongoing development so its clients can leverage e-commerce experiences to the satisfaction of their customers. “We apply carefully selected user experience technology, marketing and analytics abilities to our clients’ strategic goals to do this,” taking what it calls an “anti-Big Bang” approach to continuous deployment, says Mike Pierce, CTO of Echidna.

“Traditional e-commerce deployments were often Big Bang deployments that people developed on the basis that they had to pressure the business leaders into feeling like they had only one chance to pack as much scope as possible into a large software development project. That approach voids any practical innovation,” says Pierce. With that mindset, it can take years to finish e-commerce sites, and e-commerce companies can go out of business by the time they actually finish such a site, since it would be far out of date by then.

Echidna sees continuous deployment as one piece in a much larger agility play designed to ensure that businesses compete in digital economies, now and in the future. Continuous deployment is the ultimate goal of DevOps, an approach that enables the business to innovate fast enough to maintain the business’ sharp marketplace edge through acute, turn-on-a-dime competitive dexterity. “In order to do this, continuous deployment helps companies learn to develop high-quality software and deploy it on a rapid, reliable and repeatable schedule,” says Pierce.

Continuous Deployment Timelines and Challenges

Depending on the client, its needs and the features in the pipeline, Echidna deploys software to each e-commerce platform from monthly to daily, and at intervals in between those extremes. Echidna seeks to increase the degree of automation of each deployment over time. The challenge is that with so many different clients and platforms, Echidna must achieve its automation victories for each customer individually, solving similar and unique issues. “We are finding our greatest success using PaaS (platform-as-a-service) e-commerce platforms like Four51 because it eliminates a lot of the administrative overhead that is typical with deployments to on-premise platforms,” says Pierce.

The development model Echidna follows to deploy e-commerce sites affects each software component, even though components deploy at different times. “Payment system modifications require significantly different testing—more testing—and we must deploy them much less often than other components. Marketing components don’t need as much regression testing as other software modules and so we can deploy them much more quickly,” he says.

The most difficult software to move into continuous deployment in an e-commerce platform are the components that integrate deeply into enterprise systems. That is why Echidna advises business customers to use DevOps methodologies to deploy their enterprise production software at accelerated rates. When they do this, Echidna potentially can speed its deployment of the e-commerce platform components that are enmeshed with those production systems.

The Four51 Path, Through Jitterbit

Echidna connects Four51’s OrderCloud to the Jitterbit iPaaS integration server platform, a point-and-click integration tool. “This enables us to streamline further integrations and data exchanges with many of the disparate systems in an ecosystem,” says Pierce. Echidna sees increasing continuous deployment orchestration opportunities as more and more third-party application vendors become compatible with these kinds of integration tools.

Four51 enables an ecosystem of connected digital services and applications where e-commerce uses numerous disparate systems that exchange data and facilitate work streams in the enterprise in question, Pierce says. “As these systems eliminate disparities and we align them on the central integration and deployment standards that we use, there will be increasing opportunities to introduce clients to lean development practices like continuous delivery and continuous deployment.”

Conclusion

Continuous deployment is miles apart from what information technology is used to, especially where manual change management and change control are concerned. But once Echidna exposes its customers to continuous deployment, their managers, C-levels and boards soon begin to witness the accelerated software innovation continuous deployment provides and how this makes information technology—and the business—more nimble, both technologically and competitively.

May 25, 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
Legacy IT Challenges Continuous Delivery
Legacy information technology infrastructure has a strong effect on the potential success of DevOps. In environments where different teams have always used the same servers, change can be difficult due to inter-team coordination and limited server transparency and application inventories, says David Blank-Edelman, a 30-year systems administration/DevOps/SRE veteran and currently Technical Evangelist at Apcera.

“Unraveling the Gordian knot to bring DevOps principles and practices into that environment will be quite a challenge,” he says.

In such a legacy environment, the enterprise walks a topological tightrope stretched between one or more development machine clusters shared by multiple teams with no real isolation between teams and projects, Blank-Edelman notes. “In most cases, there is a second parallel set of machines for production and, if the business is very fortunate, for test/QA as well. There is seldom anything, however, to prevent a production workload from talking to a database server in development by mistake, which can lead to all sorts of fun.”

How to Move to CD

One solution is a policy system approach, in which the organization provides for a policy system to migrate a legacy information technology environment to a platform that uses continuous delivery (CD), Blank-Edelman says.

To create the policy system, he notes, the organization will need to address questions such as:
1. Are the workloads allocated/using only the resources that they should?
2. What is inside the workload? What is its provenance? Is it acceptable and in good order from security, coding and business requirements perspectives?
3. Where is the workload allowed to run? In which cloud? In which environment? In which country? Near what other containers?
4. Can the workload communicate with only the things it should? If I move it to another location, is this still true?
“The process of developing a policy system and then enacting it can lead an organization on a journey that brings their existing infrastructure to a much better place. If that platform can also automatically enforce the decisions that organization made during this question and answer discovery process, you can be certain that the answers to these questions stay answered,” says Blank-Edelman.

Other approaches to moving to continuous delivery include tool-first approaches in which the organization adopts one to several CI/CD/workflow tools and then makes an effort to implement those, possibly by shoehorning existing processes and runbooks into that tool or toolset.

A better tactic is the people-first or culture-first approach that focuses on how the development and operations personnel will work together to create a product vs. a project, says Blank-Edelman. While tools still have a role to play in the people-first approach, they are not the priority; rather, organizational change comes first. Once the people have made the commitment and the change, everything else will follow.

Challenges During the CD Move

It’s not the existing information technology infrastructure that presents moderate challenges to CD that is the issue; it’s the infrastructure that poses either very many challenges or very few that is the hurdle. “If you start with a more challenging situation, this will incentivize people to work very hard to reduce the associated pain points in their life,” Blank-Edelman says.

On the other hand, he notes, when an organization begins a move to CD with an infrastructure that is already in pretty good shape, you won’t often hear its people say that they should stop working on the product and work on CD all the time instead. People will still claim they have plenty to do already.

Continuous Deployment Can’t Exist Without CD

Continuous delivery starts with a code base and takes logical steps through that code base to increase confidence that it is ready for production, using a process that is as smooth, automated and loosely coupled as possible, he says. With confidence in that pipeline comes confidence in moving the result of that process into production automatically, which is continuous deployment, he adds.
April 20, 2016
If you “code” your apps, why do you still “configure” your IT infrastructure?
Industry studies and market indicators show the exploding growth of the DevOps movement, and it’s for one simple reason – in today’s application driven economy, DevOps teams have proven that they can build, test and ship applications faster than the traditional IT approach.

Businesses compete on the efficiency of delivering applications to meet the demands of the critical mass. Enterprises need the latest business applications to meet new service demands of their customers, accessed in new ways such as over mobile devices. In an application-driven economy, apps are developed and delivered via the cloud more rapidly than ever before; fast time to market is key for success and staying a step ahead of the competition.

As a result of this incredibly dynamic environment, IT teams have adopted new processes such as “continuous integration, continuous development” (CI/CD) – a radical departure from the waterfall model of application development that’s been around for decades. These people and groups within organizations that are leading the charge on CICD or agile development – to meet economic demands for the exploding cloud and mobile market place – are called “DevOps”.

However there are three big barriers that are still slowing down the time to market for apps. Unfortunately, there’s not much the DevOps folks can do since the problem lies in how underlying enterprise IT infrastructure, and specifically the networking products such as application delivery controllers (ADCs), have not kept pace with this evolution.

The reasons application delivery to market is still too slow, as well as recommended solutions, include:
1. Network admin “Human Latency”: ADCs are usually purchased by the network admins that sit within the CIO–led IT teams. As a result, the DevOps and application developers don’t have access to ADC devices. Since app developers need ADCs to test the efficacy of the apps they are building, they have to connect with the networking teams and request access to ADCs…and wait for permissions. This typically takes weeks because of the complexity involved with setting up a custom environment per app developer per app!
In a world where it takes 20 seconds to fire up a server, the human latency (measured in weeks) associated with provisioning an ADC is simply unacceptable.

The solution: A fully programmable , self-service ADC that the app developer/DevOps folks can themselves setup within seconds using RESTful API and scripting tools. DevOps needs an ADC that has zero touch provisioning, is able to auto-discover the compute/app environment, and can auto-create and auto-scale.
1. Distributed Microservices-based app architectures: Microservices have fundamentally changed how apps are built, maintained and scaled. Instead of a monolithic “black box” app that sits in one location with a “reusable or even disposable lego-block” architecture, Microservices can be written in different programing languages, loaded on various hardware and hypervisor platforms, and, most importantly, deployed across various on-premise and cloud locations.With this heterogeneity comes complexity in managing all these different environments which leads to cost and delays associated with rolling out a new application.
The solution: An application delivery architecture that can span, serve and scale all locations, while remaining one device to manage from a management perspective.
1. Geographically dispersed Dev, Test and Production teams: Many companies have the development and testing of apps done in a public cloud, but because of data sensitivity issues (or compliance) they have to run production copy of the app on on-prem data centers or private clouds.Imagine for a minute what this means – completely different environments across various cloud/on-prem locations!When doing development or testing, a certain ADC can be used on-prem – but it’s a different ADC for the real world. There can be unexpected surprises in terms of how the app actually behaves, performs and scales in a real deployment.
Solution: DevOps teams need the same consistent environment across public, private and on-prem data centers. More importantly, if the setup and operations of ADCs across environments is identical, it saves a lot of complexity and costs.

The goal of the DevOps group is to make the organization successful by increasing IT performance and delivery. It aims to make life of an app developer and tester simpler, allowing enterprises to develop and roll out their own apps faster than the competition. From a recent study by Puppet Labs, analysts noted: “We wanted to test the hypothesis that IT performance actually does make a difference to organizational performance. We found that IT performance strongly correlates with well-known DevOps practices such as use of version control and continuous delivery. The longer an organization has implemented — and continues to improve upon — DevOps practices, the better it performs. Companies with high IT performance are twice as likely to exceed their profitability, market share and productivity goals, giving them a strong competitive edge. “

Now more than ever, companies need to be committed to the DevOps model to keep up with the constantly changing business landscape. New approaches to DevOps addressing the challenges of today’s dynamic environment are available for companies to leverage for the benefit of their customers. The timing could not be better – it is now. However, an evolution of the underlying IT infrastructure such as the application delivery controllers (ADC) is not just desirable but mandatory.

About the Author/Ranga Rajagopalan

Ranga Rajagopalan, CTO and Co-Founder of Avi Networks. Over the last 15 years prior to co-founding Avi Networks, Ranga has been an architect and developer of several high-performance distributed operating systems as well as networking and storage data center products. Before his current role as CTO, he was the Senior Director at Cisco’s Data Center business unit, responsible for platform software on the Nexus 7000 product line. Joining Cisco through the acquisition of Andiamo where he was one of the lead architects for the SAN-OS operating system, Ranga began his career at SGI as an IRIX kernel engineer for the Origin series of ccNUMA servers. Beginning his journey with a Master of Science degree in electrical engineering from Stanford University and a Bachelor of Engineering in EEE from BITS, Pilani, India, he now has several patents in networking and storage.
April 29, 2015