What kubernetes and cloud9 tell us about the new industry – anyone but Amazon – James Governor's Monkchips

What kubernetes and cloud9 tell us about the new industry – anyone but amazon – James Governor's Monkchips: "We used to talk about the Anyone but Microsoft club. Arguably the triumph of open source in the enterprise was a result of the same driver. Linux was a means to avoid Microsoft operating system domination. Vendors would push an alternative, and customers would support it partly as means to hedge their bets against too much domination by a single provider.

Today the dominant vendor scaring tech providers is clearly Amazon Web Services.

One facet of today’s Anyone but Amazon coalition is OpenStack. AWS dominance led pretty much every other major tech vendor, no matter how competitive to converge on OpenStack, as an open hedge.

When pondering the implications of Microsoft’s hiring of Brendan Burns the other day, it struck me another coalition is forming, changing the fault lines of the industry. Burns is one of the founders of the Kubernetes container cluster manager project. He was at Google but just took a job as product lead for the Azure Resource Manager. He has already publicly declared he will continue to work on Kubernetes. Kubernetes has also been enthusiastically adopted by Red Hat, through it’s OpenShift platform.

So now Microsoft, Red Hat, and Google Cloud Platform are all now aligned around Kubernetes. While at first glance this new alliance of strange bedfellows might seem to be a response to the rise of Docker and the Docker Pattern – and indeed there is no doubt the enthusiastic growth in Kubernetes is partly driven by concern that Docker will own too much real estate of the new infrastructure world I believe the overarching threat is Amazon.

As Stephen has explained – the biggest competitor to open source is Amazon. There is no doubt that Amazon EC2 Container Services is going to gain wide traction. Amazon can afford to be magnanimous about Docker’s rise in a way other vendors can’t. Docker is an implementation detail rather than a potential existential threat to AWS.

This week another shoe dropped, when Amazon announced it is acquiring Cloud9, the online IDE startup. Cloud9 created Ace, which also powers the GitHub editor."



'via Blog this'

Taking Docker to Production with Confidence | Voxxed

Taking Docker to Production with Confidence | Voxxed: "Many organizations developing software today use Docker in one way or another. If you go to any software development or DevOps conference and ask a big crowd of people “Who uses Docker?”, most people in the room will raise their hands. But if you now ask the crowd, “Who uses Docker in production?”, most hands will fall immediately. Why is it, that such a popular technology that has enjoyed meteoric growth is so widely used at early phases of the development pipeline, but rarely used in production?"



'via Blog this'

Docker, not production-ready? Not so, says Docker | InfoWorld

Docker, not production-ready? Not so, says Docker | InfoWorld: 

"Yet the question remains: When will Docker be used in production? Developers have driven Docker adoption because it streamlines development and vastly simplifies deployment. But the immature nature of security and container management solutions around Docker have kept it largely a dev-and-test affair.


That may be changing. According to a recent O’Reilly Media study, 40 percent of respondents already run Docker in production. Docker has 75-plus paying enterprise customers for its data center product, which was made generally available in February, and almost 6,000 paying customers of Docker Cloud, the company’s hosted service.


It seems safe to assume that Docker isn’t being used to containerize existing enterprise applications. Instead, developers are bringing in Docker for new application deployments, greenfield opportunities that aren’t dependent on yesterday’s infrastructure. As RedMonk analyst Fintan Ryan has said:


Where we are seeing a massive difference with the use of containers is around greenfield projects. These greenfield projects generally have as close to a blank slate as you are going to find in the enterprise, and with them containers are going into production incredibly quickly -- much faster than before.


Indeed, former Appfog CEO Lucas Carlson believes Docker containers are suitable for such cloud-native applications only: “[T]he benefits of containers can only be achieved when the applications run within containers have been built-for-cloud.”


Not everyone agrees with that assessment. On the contrary, Docker CEO Ben Golub told me, “there is ample evidence to show that Docker is being embraced by early majority/pragmatist organizations,” among them Fortune 100 pharmaceutical, retail, health care, manufacturing, and media companies. Some specific customer examples:


ADP is moving its core application to a solution based on Docker Data Center and Docker Swarm

Goldman Sachs is moving 90 percent of its applications to Docker over the course of the next 12 months

The General Services Administration is basing its entire next-generation platform (which tracks $1.7 trillion) on Docker

Multiple U.S. Department of Defense agencies are running truly "mission-critical" apps on Docker"

Container Tidbits: When Should I Break My Application into Multiple Containers? – Red Hat Enterprise Linux Blog

Container Tidbits: When Should I Break My Application into Multiple Containers? – Red Hat Enterprise Linux Blog:



There is a lot of confusion around which pieces of your application you should break into multiple containers and why. I recently responded to this thread on the Docker user mailing list which led me to writing today’s post. In this post I plan to examine an imaginary Java application that historically ran on a single Tomcat server and to explain why I would break it apart into separate containers. In an attempt to make things interesting – I will also aim to justify this action (i.e. breaking the application into separate containers) with data and (engineering) logic… as opposed to simply stating that “there is a principle” and that one must adhere to it all of the time.

Let’s take an example Java application made up of the following two components:

1. A front-end application built on the Struts Web Framework
2. A back-end REST API server built on Java EE

As mentioned, this application historically ran in a single Tomcat server and the two components were communicating over a REST-based API… so the question becomes:

Should I break this application into multiple containers?
Yes. I believe this application should be decomposed into two different Docker containers… but only after careful consideration.

Big Changes in Goldman’s Software Emerge From Small Containers - The CIO Report - WSJ

Big Changes in Goldman’s Software Emerge From Small Containers - The CIO Report - WSJ:

“I have lived through all sorts of tech transitions, and this is faster than anything we have seen,” Docker CEO Ben Golub said. Docker usage increased five times during the past year, and Docker images have been downloaded more than two billion times. Docker said it is the second-largest open-source infrastructure project.

“Think of docker as two things: a format for packaging apps and an engine to run those apps,” Forrester Research analyst Dave Bartoletti said in an email. “Docker is quickly becoming the de facto standard for packaging. You can RUN dockerized apps on lots of different engines. And then when you run them, you can pick from a wide range of orchestration tools, management tools, monitoring tools, etc.”

There was concern that Docker, the company, had too much power, as both the custodian of the open-source software and a venture that sold products and services tied to it, according to Mr. Duet. In response, Docker, the company, helped form the Open Container Initiative to govern the open-source software.

Goldman uses the Docker containerization service, as well as container orchestration tools from Docker and Alphabet Inc GOOGL +0.50%.’s Google, which makes an orchestration and cluster management tool called Kubernetes, comparable to Docker Swarm. “We do both, Docker and Kubernetes, for things like running and starting,” Mr. Duet said. “Kubernetes is arguably a better scheduler…if you are going to run 1,000 containers on 1,500 computers…It is designed much more for that. Docker’s own product is great if you want to run five containers on three machines. We have both problems.”

A Docker spokesman said that “even when people use Kubernetes, they are still using the Docker container service. Some, such as Goldman, continue to use Kubernetes for larger deployments and Docker Swarm for smaller, as Docker Swarm was only made generally available in Fall of 2015 and is still being evaluated for large-scale use.”

For Goldman, the shift is part of a larger evolution, as the bank takes on more of the characteristics of a tech company. Says Mr. Duet: “We look more like Google and Amazon in many ways.”

Docker and Virtualisation links

Docker for Java Developers: How to sandbox your app in a clean environment

Continuous Delivery with Docker Containers and Java EE

A Practical Introduction to Docker Container Terminology

ANNOUNCING DOCKER TOOLBOX

Docker cheat sheet







Why I love Docker

In my view Docker will enable the IT industry to adopt to DevOps and Microservices not by being a tool, but rather being a technology that fundamentally changes how we manage IT services. The practical difference is that we can now life-cycle manage everything isolated. If one application needs a new version of a JVM or PHP library they can safely upgrade without affecting other containerized applications. This enforces the organization to embrace DevOps culture and processes.

Docker also enables us to create small independent deployments, which is the foundation of Microservices architecture. This does however add another dimension to the problem, where we have to manage service dependencies. I’ll talk more about Microservers and how to manage remote dependencies in later blogs.
So to summon up, why I love Docker is not only that it’s easy to use, gives me high density and isolation, the main reason to me is that it’s going to change how we operate and manage applications. 

Palladium: Predictive Analytics, Machine Learning framework

https://github.com/ottogroup/palladium

Palladium provides means to easily set up predictive analytics services as web services. It is apluggable framework for developing real-world machine learning solutions. It provides generic implementations for things commonly needed in machine learning, such as dataset loading, model training with parameter search, a web service, and persistence capabilities, allowing you to concentrate on the core task of developing an accurate machine learning model. Having a well-tested core framework that is used for a number of different services can lead to a reduction of costs during development and maintenance due to harmonization of different services being based on the same code base and identical processes. Palladium has a web service overhead of a few milliseconds only, making it possible to set up services with low response times.....

InfoQ: Comparing Virtual Machines and Linux Containers Performance

INFOQ: Comparing Virtual Machines and Linux Containers Performance



The paper authors ran CPU, memory, network and I/O benchmarks against native, container and virtualized execution, using KVM and Docker as virtualization and container technologies respectively. Benchmarks also include sample Redis and MySQL workloads; Redis exercises the networking stack, with small packets and a large number of clients, while MySQL stresses memory, network and the filesystem.

The results show that Docker equals or exceeds KVM performance in every case tested. For CPU and memory performance KVM and Docker introduce a measurable but negligible overhead, although for I/O intensive applications both require tuning.

Docker performance degrades when using files stored in AUFS, compared to using volumes, that have better performance. A volume is a specially-designated directory within one or more containers that bypasses the union file system, so it does not have the overhead that the storage backends may have. The default AUFS backend causes significant I/O overhead specially when using many layers and deep nested directory hierarchies.