The benefits of adopting a container-oriented development and deployment workflow are not fully realized if the adoption is only retained within the boundaries of development and test environments. The reluctance to run containers in production stems from concerns surrounding security and isolation, and a general lack of operational expertise in managing containers in a production environment.
In organizations that are at some stage of adopting containers, the decision to move them into production environments is a major consideration. It is easier to take the plunge when adopting containers for a completely new service or application, one that is ideally container native.
What does it mean to be container native? A container-native application is one that is designed and built around the lifecycle of containers and considers containers to be first class citizens of its existence. For applications that have been retrofitted to work with containers, the decision to move to production is usually harder. This refers to legacy applications, which are prone to extensive refactoring to adopt container-oriented development and deployment.
Understanding the impact on existing workflows and processes in the organizations production environments is a significant aspect of operating containers in production. Here are some workflows and processes around production that may be impacted by containers…
With LinuxCon North America approaching quickly (August 22!), The Linux Foundation is in preparation and invitation mode. This year, the organization is especially keen on opening up the event and its benefits to diverse communities. One such effort recently took place on Twitter.
During the week of June 15, @linuxfoundation asked their followers to request a free VIP all-access pass by tagging #takemetolcna (that’s Take Me to LinuxCon North America) and explaining why they should win.
Many great responses were tweeted and The Linux Foundation chose five very worthy guests. Here’s what the winners had to say:
There’s been much progress in transforming enterprise networks, but not enough organizations equate advances in software-defined networking (SDN) with increased business agility, according to a new survey from Juniper Networks and Wakefield Research of 2,700 IT decision makers (ITDMs) and business decision makers (BDMs).
Most organizations operate two networking environments. One based on SDN technology tends to be highly automated. The other is based on legacy networking technology that requires each piece of networking equipment to be manually configured. The biggest challenge in shifting to SDNs is available budget.
Mark Imbriaco has spent the past 20 years working at some of the most interesting and innovative companies in the industry, including 37Signals, GitHub, and DigitalOcean before moving on to become Co-Founder and CEO at Operable. You can also find him talking about various DevOps topics at conferences and elsewhere online.
Linux.com: Why are so many organizations embracing DevOps?
Mark Imbriaco is Co-Founder and CEO at Operable.
Mark Imbriaco: This is a tough question to answer because there are so many factors involved. In the end, the movement toward DevOps is not caused by any sort of inherent altruism in organizations but rather as a reaction to increasing demands to deliver more software, more quickly, and with fewer resources.
DevOps is focused on reducing friction and improving collaboration through the entire software delivery cycle. As more and more organizations see successful outcomes with this approach, it only becomes an easier sell. After all, it’s pretty intuitive that working collaboratively throughout the process is more efficient than attempting to coordinate across silos of development, QA, and operations at the last minute before a release.
Linux.com: Why are individuals interested in participating?
Mark: People like to feel empowered and like their voices are being heard. The collaborative nature of DevOps ensures that everyone involved in a project has the opportunity to contribute their point of view and ideas to have a positive impact even in areas that may not have traditionally been their department.
Linux.com: What’s the primary advantage of DevOps?
Mark: There is, at this point, a significant body of evidence that shows that agile, iterative development processes are able to significantly improve both the rate of software development and the ultimate quality. Rather than minutely specifying all of the details up front, practitioners of an iterative approach are able to continually learn by delivering small units of functionality and preserve the ability to adapt to what they learn along the way.
It turns out that this iterative approach is just as useful operationally. The result is systems that can be deployed more quickly, managed more effectively, and which incorporate feedback mechanisms to enable learning as a core feature.
Linux.com: What is the overwhelming hurdle?
Mark: The biggest barrier is in the variability of implementation. DevOps is not something you can buy, and no two organizations will wind up with the same implementation details in the end. This lack of a linear implementation plan can be daunting to those who are intrigued by the ideas but are already overwhelmed by a mountain of work.
The good news is that the same iterative approach that DevOps suggests for delivering projects works for adoption of the methodology as a whole.
Linux.com: What advice would you give to people who want to get started in DevOps?
Mark: As with anything, start as small as you can. Choose a small project or a new feature delivery as a testbed for a new methodology. Resist the urge to make a big splash by attacking a high profile project and apply the same iterative approach that DevOps and Agile advocate for software delivery to the delivery of changes to your human systems.
Finally, never stop learning. The real power of DevOps is the ability to continuously learn and immediately apply knowledge. The more you and your team can internalize that idea, the better your outcomes will be.
A number of assumptions and myths have sprung up around NFV during the past few years, all of which are worth unpicking.
The transition toward network functions virtualization (NFV) is in progress and, as with any technology transition, companies are proceeding with caution. The trick is figuring out which anticipated hazards are real, if any of those have already been cleared, and making sure you don’t get frozen by hazards you anticipated but which failed to materialize.
Make no mistake, the course ahead is tricky. Evangelists for new technologies can get overly enthusiastic, envisioning everyone at the finish line before anyone has cleared all the technological barriers. And then there are those companies who take off without surveying the course ahead — they’re the ones that bumble into hurdles they could have anticipated if they’d simply prepared better.
The Automotive Grade Linux (AGL) project announced the release of its Unified Code Base 2.0, implementing new in-vehicle entertainment support desired by automakers and drivers.
The new code base adds support for audio routing, rear-seat entertainment systems and apps. It follows the version 1.0 release at CES earlier this year. Automotive infotainment systems, which usually combine navigation, digital audio, hands-free phone calling and third-party apps, have been developed by automakers and equipment suppliers alike, leading to fragmentation and disparate interfaces unique to each brand of vehicle. AGL attempts to make a unified dashboard operating system, freeing automotive software engineers from individual platform development.
Among the vendors that are working on enabling OpenStack to run as a set of containers is Miranits, which is currently developing a new version of its Fuel platform to make use of Kubernetes. To date, Fuel has heavily relied on Puppet configuration management technology to help enable many functions. Moving forward, Puppet will still be a part of future Fuel releases, though not quite in the same depth as before.
As the population of DevOps practitioners grows greater in size, so does the Linux container userbase, as these often go hand in hand. In the world of Linux container implementations, Docker is certainly the most popular for server-side application deployments as of this writing. Docker is a powerful tool that provides a standard build workflow, an imaging format, a distribution mechanism, and a runtime. These attributes have made it a very attractive for developer and operations teams alike as it helps lower the barrier between these groups and establishes common ground.
In part one we learned about data and how it can be used to find knowledge or meaning. Part two explained the term Big Data and showed how it became an industry mainly in response to economic forces. This is part three, where it all has to fit together and make sense — rueful, sometimes ironic, and occasionally frightening sense. You see our technological, business, and even social futures are being redefined right now by Big Data in ways we are only now coming to understand and may no longer be able to control.
Whether the analysis is done by a supercomputer or using a hand-written table compiled in 1665 from the Bills of Mortality, some aspects of Big Data have been with us far longer than we realize.
The dark side of Big Data. Historically the role of Big Data hasn’t always been so squeaky clean. The idea of crunching numbers to come up with a quantitative rationalization for something we wanted to do anyway has been with us almost as long as we’ve had money to lose.
We think we’re doing the whole DevOps thing right — new hires can deploy on day one, Travis CI is humming along, and we own the code we ship. But then something breaks, something doesn’t go according to plan, tempers flare up, and all that warm, fuzzy collaboration seems to evaporate. What’s going on? What happened to #HugOps?
A large part of software engineering doesn’t involve code at all— it’s talking and collaborating with our teammates. Soft skills are harder to measure and quantify than performance or reliability, but they’re just as important— and while we’ll readily spend hundreds to thousands of dollars on books, courses, and training to improve our software skills, companies rarely invest in creating the culture of empathy and compassion that was behind DevOps in the first place.
