The Doppler Quarterly Spring 2016 | Page 17

either too coupled , or too decoupled from the data or other application components . Thus , it ’ s a matter of how much work it will take to refactor the applications so that they can be a set of containers as well as scale as a cluster of containers .
Part of your analysis of the use of containers should be to determine how much of a hassle it will be to actually turn an application into a container , or , more likely , into a set of containers . In some cases it ’ s just not practical , while in others , it ’ s relatively straightforward . This is the same problem you may have wrestled with during the analysis stage of porting applications to cloud platforms , so many of the same total cost of ownership metrics and models apply and can be reused here .
3 . Consider your people
Most enterprises have not moved a significant number of workloads to the cloud , much less to containers running on clouds . In many respects , the technology is not the limiting factor ; it ’ s the IT staff ’ s skillset .
As you move to containers , you ’ ll need to make a significant investment in training and hiring to obtain the skillsets you need to build and deploy containerized applications . To make this even more complicated , many enterprises are adopting DevOps as a way to automate their agile approaches to application development and so must consider the adoption of containers . In many enterprises , IT organizations have elected to adopt containers first , and then do the DevOps transformation . They do this to reduce risk , and even to cut costs .
4 . Do the strategy thing again
Just as enterprises have created and begun implementation of a cloud computing strategy , they now need to consider containers as a sub-strategy . This really just goes to the enabling technology that is a component of your overall cloud strategy and does not replace it or take it over .
At the end of the day , we ’ re deploying applications within containers , which is nothing new . The patterns of adoption we ’ ve seen with the rise of the Inter and the risk of app servers are pretty much the same , except that the technology is new . If you look at this as a revolution , you ’ ll be sorely disappointed . It ’ s an evolution at best , but one that provides a better , more scalable , and more portable platform for cloudbased applications .
Containers will have other uses with IoT applications , big data , and even traditional , on-premises systems that will stay on premises . Thus , containers are not just for clouds , but they are mostly for cloud .
5 . Test it to the limit
Enterprises moving to containers need to create test platforms to understand the real limitations of the technology . Core on this list should be :
• Scalability . What types of workloads are able to scale , and how are you able to scale them ?
• Stability . What types of behaviors or loads make the containers unstable ?
• Data . What are the limitations when containerizing data , versus leveraging data using traditional interfaces ?
• Management . How do you manage clusters of containers over a long period of time ?
• Governance and security . How do you govern and secure containers , and how does that affect scalability , performance , and stability ?
Containers are here to stay
The use of containers is growing like crazy within enterprises , and the vendors in this space have all of the funding they need to make the improvements that enterprises and cloud providers demand . That said , containers don ’ t solve all problems . Enterprises need to make sure their eyes are wide open as they move to the technology .
Users of containers will learn a lot more about the technology as the space continues to grow and adoption spreads unabated . Along the way you should expect some pleasant surprises , and some not so pleasant . The good news is that you ’ ll better understand the limits of this technology and how you can best leverage it to serve the business .
SPRING 2016 | THE DOPPLER | 15