![\"\"](\"http:\/\/europe.dockercon.com\/images\/logo-dockercon-eu-dates-transparent.png\"){kind=spacer}
<\/p>\n<\/p>\n
At DockerCon EU<\/a> there was a panel discussion<\/a> on\u00a0the future of micro services. \u00a0There were some very good insights there that I wanted to capture as well as some things I took away from it:<\/p>\n Most of this is from Adrian Cockcroft<\/a>. \u00a0He has really emerged as a visionary in the open source DevOps world largely based on his work at Netflix.\u00a0(Fun fact or name dropping moment: When Adrian worked at eBay and I was at IBM we worked together on a GPFS project, and he was the one who introduced me to LinkedIn)<\/p>\n Adrian and the panel basically said that all middleware or infrastructure management should be open source and only the SaaS based applications are things people will pay for. \u00a0I wholeheartedly agree with this. \u00a0 There are\u00a0two arguments that really stood out to make this point:<\/p>\n 1. \u00a0The days where a company can work in NDA mode for 12 months on a project and then come out with a product for infrastructure management is too slow. \u00a0By that time an Open Source project has gone through 5 iterations and has more functionality.<\/p>\n 2. \u00a0People become suspicious of projects like middleware that require a huge investment of time to become knowledgeable on. \u00a0Why would I want to gain skills on your proprietary middleware suite that may be inferior to something that is open source? \u00a0Open Source skills are more transferrable than a proprietary system.<\/p>\n I think the next hotness to emerge (that is already emerging) is a way to manage micro services running in your data center, whether that be a private or public cloud. \u00a0This will do more than just manage your docker containers. \u00a0There will be networking functionality and application queuing schedulers. \u00a0At present there seems to be two good solutions:<\/p>\n 1. \u00a0AWS, as they have already started with their Docker Schedule. \u00a0This is still pretty remedial, but don’t count AWS out.<\/p>\n 2. \u00a0An open source project.<\/p>\n There will undoubtedly be proprietary solutions. \u00a0I could see VMware deciding they need to manage docker containers in vSphere or something, and that could be nice for them. \u00a0But I think these solutions will fail. \u00a0The one that will emerge will be an open source tool championed by a community of very smart people.<\/p>\n Projects I\u00a0see arising this year are things like\u00a0Kubernetes<\/a>, Panamax<\/a>, Swarm<\/a>, etc. \u00a0These are all ways to manage containers and have a huge head start on any enterprise projects. \u00a0I would love nothing better for a large company, like my employer, to spend time and develop tools like this for networking in an open source model. \u00a0Something that is completely open, but backed by a big company that can support it.<\/p>\n One big epiphany I had while watching the panel is that micro services brings the infrastructure management closer to the application side of the house, furthering blur the lines between infrastructure and developers. We’ve talked about how the lines are blurring between storage, compute, and networking, but we should also understand that these lines are being blurred between development and infrastructure: \u00a0This is what DevOps is.<\/p>\n