DockerDevOps

#docker / containers allow you to tool around vm sprawl because containers are so much more portable and, well "contained", than using server instances.

honestly, it's not technology innovation. It is supporting the business units at a velocity that they are demanding. In fact, IMHO the tooling, culture, and process is all in support of this

exciting opportunities exist in getting traditional enterprises to evolve ioT platforms in a rapid manner creating new lobs and markets

@lars30 need to be careful though...container sprawl will be a real problem

There are a number of opportunities for #docker. 3rd Party software, adoption and conversion to containers, management, and pure development of new apps...

@chrisciborowski container sprawl is definitely coming. if theres a way to make it easy to customize there's a way for it to be easily disorganized. Sprawl is also proof of utility.

@lars30 totally agree container sprawl is coming @stu said this on theCUBE at #openstack summit

same thing happened with VMware. Adoption, then the tech teams made VM's until the dam broke. Lots of stale VM's taking up valuable real estate.

how we handle this is going to be a major change for IT, as to be handled correctly we need to be talking about artifacts, not a container "at rest" and that is what I believe @lars30 is getting at :)

@GFleming Software solves lots of these issue with automation

@chrisciborowski the culture shift is so huge on this tech. I'm comforted by two things 1) how much more tech savvy most corp business units are today 2) how focused the tech is on "time to value" with automation and optimization.

@lars30 it is a product of our own success. While folks are more "tech savvy" they have less knowledge of how tech works. That is a big challenge for us.

that's a good one...let's talk about CaaS first, as it has an impact on K8s

K8s is one of the many evolving methods for orchestrating/managing containers which approaches from he app side

IMO, Kubernetes represents the future of container management and microservices. Google gave us cgroups and namespaces which is the basis for modern containerization, now they are giving us their key differentiating methods for managing systems..

What the heck is "microservices" is this a buzzword or something real?

..at scale over the past 15 years in a nicely wrapped and packaged offering for the masses. Googles-scale container orchestration for everyone!

Microservices is the reincarnation of SOA, with lessons learned. It's a buzzword in that no one seems to have a definition nailed yet, but it is real. Today, applications are built and comprise of many small independent services, "micro" service.

totally real, see https://en.wikipedia...

@asynchio certainly has it's place, and we are tracking it very closely...but our experience shows that not every shop will need all K8s brings to bear. See my comment about learning curves above

@asynchio in practice I've seen application scope, overhead impact and degree of desired control be deterministic in which software packages are selected include K8s

@asynchio SOA strict guidelines are what proved to be an issue...contract and schema

I like the way @adrianco puts it, "a service-oriented architecture composed of loosely coupled elements that have bounded contexts"

@asynchio yep...agree with @adrianco 100%

microservices are just a design pattern for how you bundle the functality of containers. In that they are a metaphor they are "real" if you implement with that approach. Products that are collections of containers are proly using microservices.

do you mean software using CaaS or actually building your own CaaS?

two questions: what the heck is Containers as a Service and two how do I build a container software mgt system

Can #docker own the orchestration of all containers or just their own containers

I think the best examples of Containers as as service actually comes from joyent

they have a service where containers represent the base unit as the commodity for charging the end user.

this can lead to more precision over what we pay for compute

today #docker orchestrates for their containers only

no, i see software being collections of containers that do something valuable. Individual containers should IMHO be doing very simple specific things. So any given container won't likely be a product, but parts of a product.

. @lars30 I was saying on @theCUBE at #openstack summit that containers and kubernetes will unleash massive value; TCP/IP created network than internetworking here "interclouding" is about containers and orchestration imho

yes, I think that's the right. Containers also do data transformation, business rules evaluation, lots of things you probably could lump under orchestration.. but are really individual things you need to ramp up and down based on demand.

@lars30 orthogonality.

@chrisciborowski bit arch there. say more?

@lars30 meant that when used properly, the parts (containers) are as small as possible and provide a minimum functionality...if other func/capability is needed, it should be provided by a different unit of work

@chrisciborowski thanks, gotcha.

yes, yes, and yes. But it also can create new problems that didn't exist prior...especially with new technologies which may be adopted on an individual basis.

@chrisciborowski can u give some examples?

take for instance a model where the developer is not managing the application through the stack and across dev/prod... now you are asking ops to learn at a steep curve

@chrisciborowski so better output only if your org is agile enough to learn at the new pace?

-> lower technical debt -> leading to feature delivery as the prime metric in measuring success

@jbradley888 ah, less waste. makes sense.

yes...or alternatively working with a team who can fill gaps and provide advisory services.

also hopefully greater innovation

that depends. You can certainly use a devops model for monolithic application development and see an ops benefit, but the real dev benefit is when paired with microservices, distributed apps.

@chrisciborowski interesting, my #datascience simulations show devops + innovative new svcs == disruptive effect. is that what is happening here?

exactly what I am saying - the new tech requires a different application architecture.

@chrisciborowski ok, cool. can you recommend a place to read more/get examples?

first, get to know distributed applications...the twelve-factor app http://12factor.net

then distributed computing, its not anything like legacy IT

and lastly, understanding the team and what cultural model works best considering the companies expertise (netflix, app centric) or more traditional cross-functional teaming

I'd argue 100x. WebEx touched on it at OpenStack. From quarterly releases to multiple daily releases.

10X is a good starting point as learning curves and existing technical debt must be addressed...but long term it changes the nature of the development cycle to where reductions in time become meaningless as goals change

Not sure how realistic that is. Cracking team, existential threat, big economies of scale. 10x+ for sure.

this involves modifying existing business units which are resources. mis-management of the resources could hurt and streamlining could get greater returns. just saying...

@epowell101 crawl, walk, run - to begin with 10x but that should increase if done correctly

@epowell101 but many organizations have yet to define and collect metrics on current development & release, as well as technical debt, so we need to address that first

@chrisciborowski the transition from mtbf to time to feature delivery is the most difficult transition for many traditional enterprises but sometimes the most meaningful