devopsy.kinsta.cloud

Tag: docker

Red Hat launches platform to support Docker, Kubernetes and enterprise-grade containerization

Red Hat continued its momentum to capture a piece of the containerization market last week with the official launch of its new Red Hat Enterprise Linux Atomic Host operating system. According to Red Hat executives, this is a natural progression in the Red Hat ecosystem as more of the company’s customers embrace Docker and other containerization technologies.

“Today, with the launch of Red Hat Enterprise Linux 7 Atomic Host, we are doing the same for Linux containers, bridging innovative open technology with the stability and security required by the enterprise,” said Jim Totton, vice president and general manager of the platforms business unit at Red Hat. “More than just an addition to the Red Hat Enterprise Linux portfolio, Red Hat Enterprise Linux 7 Atomic Host showcases the future of the enterprise application, a powerful, flexible application greater than the sum of its parts, and entirely fueled by the power of open innovation.”

–THIS STORY HAS BEEN MOVED TO CONTAINER JOURNAL–

March 10, 2015
Are VMs becoming El Caminos?

In 2010, it looked as if virtualization had won. We expected all servers to virtualize workloads and the primary question was which cloud infrastructure manager would dominate. Now in 2015, the picture is not as clear. I’m seeing a trend that threatens the “virtualize all things” battle cry.

Really, it’s two intersecting trends: metal is getting cheaper and easier while container orchestration is advancing on rockets. If metal can truck around the heavy stable workloads while containers zip around like sports cars, that leaves VMs as a strange hybrid in the middle.

What’s the middle? It’s the El Camino, that notorious discontinued half car, half pick-up truck.

The explosion of interest in containerized workloads (I know, they’ve been around for a long time but Docker made them sexy somehow) has been creating secondary wave of container orchestration. Five years ago, I called that Platform as a Service (PaaS) but this new generation looks more like a CI/CD pipeline plus DevOps platform than our original PaaS concepts. These emerging pipelines obfuscate the operational environment differently than virtualized infratructure (let’s call it IaaS). The platforms do not care about servers or application tiers, their symantec is about connecting services together. It’s a different deployment paradigm that’s more about SOA than resource reservation.

On the other side, we’ve been working hard to make physical ops more automated using the same DevOps tool chains. To complicate matters, the physics of silicon has meant that we’ve gone from scale up to scale out. Modern applications are so massive that they are going to exceed any single system so economics drives us to lots and lots of small, inexpensive servers. If you factor in the operational complexity and cost of hypervisors/clouds, an small actual dedicated server is a cost effective substitute for a comprable virtual machine.

I’ll repeat that: a small dedicated server is a cost effective substitute for a comparable virtual machine.

I am not speaking against virtualize servers or clouds. They have a critical role in data center operations; however, I hear from operators who are rethinking the idea that all servers will be virtualized and moving towards a more heterogeneous view of their data center. Once where they have a fleet of trucks, sports cars and El Caminos.

Of course, I’d be disingenuous if I neglected to point out that trucks are used to transport cars too. At some point, everything is metal.

March 6, 2015
Docker tinkers with Docker Hub for performance improvements

Docker’s strengthening its infrastructure components to accommodate the volume of use and wide range of use cases that inevitably crop up from such hockey-stick growth. The latest improvements come by way of refinements made to Docker Hub over the last month, according to an announcement made by the company yesterday.

The Docker Hub team reported that many of the changes were precipitated by performance issues experienced at the end of 2014, following the addition of security enhancements to prevent brute force login attempts. They reported that the enhancements added “overhead to the login process.”

“Under normal load there wasn’t much difference, but as the number of login attempts increased the site performance started to degrade,” they wrote. “The decreased performance affected not just the Docker Engine logins, push, and pulls, but also the Docker Hub website as a whole.”

In the process of identifying immediate issues causing the problem, Docker’s engineers audited the entire system and is in the middle of rearchitecting the authorization, push and pull system to improve performance and isolate systems for a bulkhead effect, ensuring that there aren’t cascading problems.

In the immediate term, some of the fixes already made include bulking out infrastructure capacity, including a tripling of servers in the Docker cluster for four-times the compute power and a production database upgrade for twenty times the RAM. It also improved login infrastructure to include added database indexes and more caching. The team also tuned queries for speed and fixed an issue that was causing database locks. Docker also switch its background worker queue broker from Redis to RabbitMQ and moved background workers to their own server cluster. Additionally, improvements were made to monitoring and metrics gathering, as well as to search functions.

Meanwhile, down the line they expect to make further improvements that include API throttling, breaking up larger services to improve scalability, replacing the brute force prevention library with a better performing library and adding API metrics and monitoring to head off performance issues earlier.

“We have made some good progress, but we are not finished yet, and we still have a lot more planned,” the Docker Hub team wrote. “We will continue to make improvements with every release, so that Docker Hub only gets faster and more reliable as time goes on.”

Such hiccups as the ones in December are understandable given the meteoric growth of the Docker community. Even just six months ago, the total number of downloads of Docker were under 3 million. By December that number had risen to 100 million. In spite of some questions about the security of Docker containers, Docker’s trajectory seems promising. Just in September the company closed on $40 million in series C investment from Sequoia and over the past few months it has been announcing a number of high-powered partnerships, including those with VMware, Microsoft and AWS.

Docker’s most recent partnership was announced last week when it teamed up with Google so that the online giant could offer a private registry service for Docker on its cloud platform. Currently in beta, the Google Container Registry will provide Google cloud customers with secure hosting, sharing and management of private container repositories that will include strong access control and server-side encryption.

January 27, 2015
Gartner gives Docker security an ambivalent thumbs up

As organizations continue to evaluate wider spread use of containerization to enable continuous deployment, security concerns around the wildly popular Docker keep popping up. Last week, an analyst with Gartner published a report that gave Docker security positive marks with some big caveats.

Written by Joerg Fritsch, the report examined the security properties of Docker. According to Fritsch, Docker is effective at resource isolation and has already just about attained parity in secure operations management and configuration governance with Linux OS and hypervisors . But where Docker containers fall short is on the management end.

“They disappoint when it comes to secure administration and management, and in support for common controls for confidentiality, integrity and availability,” Fritsch wrote, explaining that this could improve as Docker refines its libswarm and nsenter APIs.

As things stand, Fritsch recommends that organizations that don’t need to emulate a virtual private system should standardize on nsenter for interacting with running containers, and protect nsenter by limiting the input set. He also recommends that when working at scale, organizations should select a framework for managing resources and deploying containers, and consider using SSL/TLS wrappers for the Docker/Swarm API for the sake of integrity and confidentiality.

Meanwhile, Fritsch particularly calls out the lack of endpoint protection platform and encryption tools for Docker containers, explaining that the outlook is “grim” on this front.

“Traditional EPP and encryption vendors have not yet recognized containers as an area that they need to pursue and secure in the future,” he says, explaining that organizations have to mitigate risks through application whitelisting, SELinux or by using a strategic DevOps tool chain to automate and secure their containers, essentially making “containers self-assessing entities.”

Third party vendors may take more note of Docker as 2015 progresses, particularly if Docker’s growth follows the same trajectory in 2014. From June to October alone, Docker’s downloads grew from 3 million to 21 million. And last fall Docker received venture support for future growth by way of $40 million in additional funding—following up a previous round of $15 million in funding earlier in the year.

However, security concerns around Docker have started gather like storm clouds. In fact, security objections over Docker were a big reason for the introduction of the Rocket containerization project by CoreOS in early December. That announcement came swift on the heels of the release of the 1.3.2 version of Docker Engine, which took care of a number of vulnerabilities that could be exploited through a malicious Dockerfile, image or registry. It also added added a security feature for validation of images in containers. However, by late-December, security pros were knocking that verification function.

“Docker’s report that a downloaded image is “verified” is based solely on the presence of a signed manifest, and Docker never verifies the image checksum from the manifest,” wrote Jonathan Rudenberg, co-founder of Flynn, in a long explanation of the insecurities in Docker’s image downloading process. “An attacker could provide any image alongside a signed manifest. This opens the door to a number of serious vulnerabilities.”

January 20, 2015
Containers Are Designed For an Antiquated Application Architecture

In his most recent GigaOm article, “We’re finally headed towards autonomous, self-migrating containers for cloud-application automation“, David Linthicum discusses the value that containers, such as Docker and CoreOS Rocket, are bringing to DevOps and cloud systems management. For the record nothing Dave states in the article is incorrect with regard to the expressed value that containers provide for portability, however, there is an issue with the big picture view discussed for the role of containers in cloud application delivery.

Containers are predicated on the goal of deploying and managing n-tier application designs. By their nature, containers manage n-tier application components, e.g. database servers, application servers, web servers, etc., at the operating system level. Indeed, portability is inherent because all operating system and application configuration dependencies are packaged and delivered inside a container to any other operating system platform. Containers are…

–THIS STORY HAS BEEN MOVED TO CONTAINER JOURNAL–

January 13, 2015
Equalizing IT infrastructure with DevOps

IT is getting more complex. Managing on-premise servers, cloud servers, and hybrid environments that span various operating systems and standards creates challenges for IT admins. DevOps technologies and platforms, however, can be an equalizing force among the cloud chaos—making it easier for organizations to deploy servers and applications quickly and consistently regardless of platform or environment.

Once upon a time most organizations were fairly standardized. Servers were located on-premise in some sort of closet or data center, and IT admins knew exactly what operating system they were working with. Now, those servers may be physical or virtual, on-premise or in the cloud, Windows or Linux, Azure or Amazon, and in many cases IT admins are dealing with an infrastructure that amounts to an all-of-the-above approach.

As the name implies, the core of the DevOps movement is to remove the barriers between developers and operations. Many of the tools and technologies that comprise the DevOps movement, however, also have the added benefit of providing a consistent, modular approach to developing and deploying applications and infrastructure. Those technologies also reduce friction between on-premise and cloud environments, and allow organizations to streamline operations across different platforms and operating systems.

“One of the biggest reasons for the increased interest in DevOps tools and practices is because businesses have to move and iterate faster today than at any other time in history,” declared Tim Zonca, director of product marketing for Puppet Labs. “So IT teams are pursuing DevOps flows, where development and operations practices, systems, and tools work in lockstep.”

As IT infrastructures become more complex, DevOps becomes more crucial. Expansion of IT across physical, virtual, and cloud environments make even minor inconsistencies into critical issues as organizations grow, and brings additional burden to address those problems.

Many DevOps technologies revolve around using virtualization to deploy applications inside pre-built environments, or modular blocks that can be deployed and re-used across various platforms and environments. These tools remove most of the chaos, and enable organizations to simplify deployment across virtually any infrastructure.

Docker is a great example of the impact DevOps is having. Docker containers enable developers to package an application, and transport it anywhere Docker containers are supported without modification to the virtual environment. As Docker continues to spread influence across Azure, Parallels, and other cloud and virtual platforms, it is asserting itself as an equalizing force that eliminates the need to even care what the underlying infrastructure or operating systems are.

Puppet Labs is another illustration of the equalizing force of DevOps. Zonca explained, “Puppet makes it easy to standardize and add consistency to your infrastructure so you can make fast, repeatable changes across physical and virtual machines, on premises or in the cloud. Because these tools create a predictable environment, you don’t have to worry about a simple update taking down an entire system your business relies on.”

James Bottomley, CTO of server virtualization for Parallels, suggests that even DevOps has its limitations, though, and that it could eventually get in the way of advancing productivity. “However, one cannot help thinking that DevOps, while a leveler, is also a separator because it is only accessible to developers with the Ops skill, not to all developers. Additionally, the utility of DevOps depends upon the availability of Infrastructure and, while IaaS is clearly the dominant Cloud technology today; it won’t be forever. At that point, one might imagine that the DevOps technique might impede rather than assist the next paradigm shift in the cloud.

For now at least, DevOps technologies enable developers and IT admins to take a modular, platform-agnostic approach to many aspects of applications and infrastructure to simplify and streamline regardless of the underlying environments or operating systems.

January 5, 2015
Native support for Docker apps coming soon to Parallels

When I think of Parallels, the first thing that comes to mind is virtual machines. I have used Parallels for years as a means of running a virtualized instance of a Windows operating system from within Mac OS X. In addition to virtual machines, though, Parallels was also doing containers before containers were cool, and announced last week that it will soon include native support for Docker applications as well.

Parallels was working with container technologies years ago with Virtuozzo and the open source OpenVZ platform. The company claims to be the most widely-deployed containers platform in the world, with over one million instances. With the launch of native Docker support, service providers will be able to provide container-based virtual private servers on the Parallels Cloud Server platform to customers that want to build with Docker applications. Parallels

“A challenge customers face today is running Docker images in a virtualized environment based on a hypervisor,” explained James Bottomley, chief technology officer of virtualization for Parallels. “This takes a core benefit of Docker—that the applications run in containers at higher density and performance—and reduces that benefit considerably.”

Bottomley added, “With Parallels solution, the service provider can offer the customer an environment where Docker is running on top of Parallels Cloud Server containers-based virtualization for optimal performance and at high-density.”

Why does this matter? I spoke with Bottomley myself to get more information. He told me that the primary advantage of containers—particularly in the cloud—is they have different elasticity and density capabilities than a hypervisor. It is faster and easier to scale containers than entire virtual machines.

There is a disadvantage as well. Bottomley stressed that container technology requires that all of the containers share the same kernel. So, it’s not possible, for example, to launch a Windows-based container on a Linux kernel, or a Linux-based container on a Mac OS X kernel.

The inclusion of native Docker support in Parallels Cloud Server will be significant for smaller companies. Large enterprises like Microsoft or Amazon have virtually unlimited resources to invest in scalability. They can simply run container apps in separate hypervisor instances, and just continue to add more hypervisor instances to meet demand, but that is a costly and inefficient way to address scalability.

With Docker apps running on Parallels Cloud Server, smaller cloud service providers will have a secure, high-density virtual server environment with the elasticity and scalability to compete with much larger public cloud providers. Bottomley told me that the Parallels solution with Docker containers reduces the physical server overhead by a factor of one-third.

Philbert Shih, managing director, Structure Research agrees there is significant market opportunity for cloud service providers to deliver a cost-effective platform for developing and deploying Docker applications. “The answer lies in building an optimized infrastructure environment that is dense and scales, while being able to maintain high levels of performance and facilitate portability of workloads.”

The Parallels announcement is just the latest in a string of victories for Docker. Microsoft added support for Docker containers on Linux virtual servers in Azure earlier this year, and recently announced a partnership with Docker to bring native container support to the next iteration of Windows Server.

As the container concept gathers mainstream steam, though, Docker also faces increasing competition from rivals like Rocket. Expanding Docker’s sphere of influence with native support on popular, and widely-used platforms will help to cement it as the de facto leader of container apps.

The update to Parallels Cloud Server to introduce native Docker support is expected in the first quarter of 2015.

December 18, 2014
Copying Data From One Docker Container to Another

Docker containers can easily be compared to a directory. A Docker container holds everything that is required for an application to run including its dependencies and can be started, stopped, moved and deleted at will. When containers are activated they use Linux kernel namespaces. Each container operates in isolation from the server apart from networking and storage. Each container is created from a Docker image and one can have multiple containers running, depending upon the server hardware capacity. Docker containers are the run component of Docker.

What are Docker images?

Each Docker container is created from a Docker image, which can be built either by executing commands manually or automatically through Dockerfiles. Images can be basic either consisting of the operating-system fundamentals or a pre-built stack ready for launch. They are read only templates and consist of series of layers, so any new action or update leads to the addition of new layer on top of the previous one rather than replacing whole image entirely. This is how a new container is made.

Copying data from one Docker Container to another:

Copying of data from one container to another is essential and most important feature of Docker containers. Copying data to another container means having a backup that could be used if any kind of disaster occurs out of any situation in real time scenario.

Using Data Volume Containers:

Data volume is a directory available to a container but it is located outside of its root file system. Sharing data between the containers allows volume to bypass image layering. Any changes in the data are made directly, containers have dedicated directories in the /var/lib/docker directory and volumes are stored separately in/var/lib/docker/volumes/ by default. –v option of docker run can be used to copy volume data between the two containers.

How to copy content from one container to another -An Illustration

In this example we assume that Docker is running two instances of data volume container image mymod/dvc: v1. Following are the commands that are used to start the container

# docker run –d –name dvc1 mymod/dvc:v1

# docker run –d –name dvc2 mymod/dvc:v1

Now to copy data to the host and to even mount the volume from another container, use cp command to copy data

[root@host ~]# docker run –rm –v /var/tmp:/host:rw \ –volumes- from dvc1 cp –r/var/www/html/host/dvc1_files

The container mounts the host directory /var/tmp read-writable as /host, mounts all the volumes, including/var/www/html, that dvc1 exports, and copies the file hierarchy under /var/www/html to /host/dvc1_files, which corresponds to /var/tmp/dvc1_files on the host.

Now to copy data from dvc1 host to another data volume container we use following command

[root@host ~]# docker run –rm –v /var/tmp:/host:ro –volumes-from dvc2 \ cp –a –T /host/dvc1_files /var/www/html

The container mounts the host directory /var/tmp read-only as /host, mounts the volumes exported by dvc2, and copies the file hierarchy under /host/dvc1_files (/var/tmp/dvc1_files on the host) to /var/www/html, which corresponds to a volume that dvc2 exports.

Another method with which one can copy data is ADD command, a Dockerfile command. Source and destination form the two arguments for ADD command to run successfully. It copies the files or data from the source container into the destination container with its own filesystem.

Conclusion:-

Docker will certainly expose nicer ways to grow container service to support wider deployment platforms and the community is surely expected to build service layers around. Development of core capabilities, cross service management and messaging between the containers are the paths set by Docker. We’ve tried to demonstrate via this article that data can be copied and replicated in another Docker container thus can be used in any case of disaster as well as recovery. Docker provides the ability to easily differ containers. It improves debugging, fast sharing of the environment and quick deployment. Docker has an ability to put the containers directly from Dev or QA onto AWS. User can share data through volume containers, mount host directories to containers or even can export data from containers to archive files thus very flexible.

December 9, 2014
Docker vs VMs

All applications have their own dependencies, which include both software and hardware resources. Docker containers bring numerous unknown tags to the chart as compared to existing technologies in use. In terms of technology, it’s quite interesting in scenarios where it helps in promoting cloud portability by running the same applications in different virtual environments. Docker is an open platform for developers, it’s a mechanism that helps in isolating the dependencies per each application by packing them into containers. Containers are scalable and safer to use and deploy as compared to previous approaches.

Virtual machines are used extensively in cloud computing. Isolation and resource control have continually been achieved through the use of virtual machines. Virtual machine loads a full OS with its own memory management and enable applications to be more efficient and secure while ensuring their high availability.

How are Docker Containers different from a Virtual Machine?

Virtual machines have a full OS with its own memory management installed with the associated overhead of virtual device drivers. In a virtual machine, valuable resources are emulated for the guest OS and hypervisor, which makes it possible to run many instances of one or more operating systems in parallel on a single machine (or host). Every guest OS runs as an individual entity from the host system.

On the other hand Docker containers are executed with the Docker engine rather than the hypervisor. Containers are therefore smaller than Virtual Machines and enable faster start up with better performance, less isolation and greater compatibility possible due to sharing of the host’s kernel.

Docker Containers versus Virtual Machines:

When it comes to comparing the two, it could be said that Docker Containers have much more potential than Virtual Machines. It’s evident as Docker Containers are able to share a single kernel and share application libraries. Containers present a lower system overhead than Virtual Machines and performance of the application inside a container is generally same or better as compared to the same application running within a Virtual Machine.

There is one key metric where Docker Containers are weaker than Virtual Machines, and that’s “Isolation”. Intel’s VT-d and VT- x technologies have provided Virtual Machines with ring-1 hardware isolation of which, it takes full advantage. It helps Virtual Machines from breaking down and interfering with each other. Docker Containers yet don’t have any hardware isolation, thus making them receptive to exploits.

As compared to virtual machines, containers can be faster and less resource heavy as long as the user is willing to stick to a single platform to provide the shared OS. A virtual machine could take up several minutes to create and launch whereas a container can be created and launched just in a few seconds. Applications contained in containers offer superior performance, compared to running the application within a virtual machine.

There is an estimation being done by Docker that application running in a container can go twice as fast as one in a virtual machine. Also, a single server can pack more than one containers as OS is not duplicated for each application.

Virtual Machines and Containers: better together

You can sometimes use a hybrid approach which uses both VM and Docker. There are also workloads which are best suited for physical hardware. If both are placed in a hybrid approach, it might lead to a better and efficient scenario. With this Hybrid setup, users can benefit from the advantages if they have workloads that fit the model.

Following are a few of them, that explain how they work together as a Hybrid:

1). Docker Containers and Virtual Machines by themselves are not sufficient to operate an application in production. So one should be considering how are the Docker Containers going to run in an enterprise data center.

2). Application probability and enabling the accordant provisioning of the application across infrastructure is provided by containers. But other operational requirements such as security, performance and capacity management and various management tool integrations are still a challenge in front of Docker Containers, thus leaving everyone in a big puzzle.

3). Security isolation can be equally achieved by both Docker Containers and Virtual Machines.

4). Docker Containers can run inside Virtual Machines though they are positioned as two separate technologies and provide them with pros like proven isolation, security properties, mobility, dynamic virtual networking, software-defined storage and massive ecosystem.

Apples to apples comparison: On a physical host with a certain configuration and Virtual Machines with the same configuration running an identical running same number of docker Containers with the same performance on both?

Who wins amongst the two?

Answer to this question so far cannot be ascertained but depending upon their configurations and constraints one could say that containers are overcoming virtual machines. Application design is the one standpoint suggesting which one of the two should be chosen. If application is designed to provide scalability and high availability then containers are the best choice else application can be placed in a virtual machine, though Docker containers have surely challenged virtualization market with containers. Well, keeping the debate aside, it is easy to say that containers in Virtual Machines are twice as robust as one without the other.

Conclusion:-

Docker Containers are transforming the DevOps (developer operations) landscape as an important tool in DevOps arsenal. The use cases for Docker Containers within the realm of DevOps are plenty. Running apps over Docker Containers and then deploying anywhere (Cloud or on-premise or any flavor of linux) is a reality now.

Working in heterogeneous environment, Virtual Machines provide high flexibility whereas Docker containers’ prime focus is on applications and their dependencies. The prime goal of the article is to compare the both on the basis of performance. Docker Containers promise to port application stacks across cloud easily by using each cloud’s Virtual Machine environment to deal with the cloud. This represents a useful capability that has to be implemented in a more complex and tedious way today without Docker Containers. Its not about abandoning Virtual Machines but to advocate in favor and design for the use of Docker Containers in addition to Virtual Machines when necessary. We don’t think Docker Containers could completely wipe out Virtual Machines.

November 24, 2014
Microsoft determined not to get left behind by DevOps

Microsoft is a massive company—a behemoth with a lot of inertia, and a lot of bureaucracy in place that make it difficult to adapt quickly. Under Satya Nadella, however, Microsoft is striving to re-invent itself, and—to the extent that it is possible—become more agile. For evidence of Microsoft’s new philosophy, look at how Microsoft is aggressively embracing concepts like open source and DevOps that used to be viewed as pariahs.

I wrote recently about the partnership between Microsoft and Docker. Microsoft added support for Docker containers in the Azure cloud platform within Linux virtual machines earlier this year, but then it upped the ante by announcing that it will support Docker natively in the next version of Windows Server, and that it is working closely with Docker on an open source project to drive development of the Windows engine for Docker.

“An important aspect of this announcement is the noticeable speed we are observing Microsoft move to implement open source technologies,” explained Al Gillen, an analyst with IDC, in a report about the relationship between Microsoft and Docker. “The company appears to be determined not to be left behind as the velocity of open source developer technologies accelerates. The company appears to be willing to integrate competing technologies, or technologies from competing ecosystems at a faster pace and with less hesitation.”

Docker isn’t the only piece of the puzzle, either. Earlier this year Microsoft joined forces with Chef and Puppet Labs, and integrated both of those popular DevOps platforms into Azure as well. Incorporating Chef and Puppet Labs gives IT admins more flexibility to deploy, configure, automate, and manage VMs in Azure.

What the new philosophy really represents is a realization. Nadella’s Microsoft sees the writing on the wall, and understands that it’s a new world. Technologies have changed, and the way companies and individuals use technology has changed, and the days of dominating the tech universe as a virtual monopoly are gone. The two choices facing Microsoft were to either stubbornly cling to its former glory and die a slow, painful death, or adapt and embrace change in order to remain relevant, and continue to play a vital role. Thankfully, it seems Microsoft has chosen the latter path.

What does embracing change look like? Microsoft appears to be taking a two-pronged approach. On the one hand, Microsoft is changing internally to shed some of its entrenched bureaucracy and enable it to function with more agility. It is also striving to keep up with new technologies itself—buying Nokia to bring smartphone manufacturing in house, developing the Surface tablets, rolling out the Microsoft Band wearable health tech, and other initiatives demonstrate that Microsoft is working hard to break free from the shackles of its own past, and find ways to keep up with the changing tech landscape.

The second—and arguably more important—prong is how Microsoft is addressing the new multi-vendor, cross-platform world we live in. Microsoft recognizes that it is not the only game in town, but it has a vested interest in ensuring that customers continue to rely on Microsoft tools no matter what platform they choose. To that end, Microsoft is doing a much better job of offering its own products and services across a wider range of devices and platforms.

The new Microsoft represents a win-win-win scenario. It’s a win for Microsoft because it enables the company to shift and evolve to stay relevant with a rapidly-changing tech landscape. It’s a win for open source and DevOps because companies of all sizes are built around Microsoft operating systems and applications, so incorporating support for open source and DevOps tools exponentially increases the potential customer base. Finally, it’s a win for the customers themselves because they get to maintain their existing investments in a Microsoft infrastructure, while also gaining access to new tools that enable greater automation and efficiency.

November 3, 2014