Electric Cloud’s POV on Containers
Electric Cloud’s POV on Containers
Bottom line: Containers accelerate software updates from every stage of the process, from developer check-in to production release.
Join the DZone community and get the full member experience.Join For Free
Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.
Thanks to frequent contributor Anders Wallgren, CTO at Electric Cloud for sharing his thoughts on the state of orchestration and deployment of containers for DZone’s upcoming Containers Research Guide that will be published this month.
Q: How is your company involved in the orchestration and deployment of containers?
A: Electric Cloud offers a DevOps Release Automation platform – ElectricFlow. The solution reduces the time, risk and cost of software delivery by automating and accelerating software updates from developer check-in through to Production release. As part of that, many of our users – both enterprises and small teams – are looking into Containers for various stages throughout their pipeline- both for build/test, as well as deploying containers (or microservices-based applications delivered in containers) into large-scale Production environments.
Q: What do you see as the most important elements of orchestrating and deploying containers?
A: We see a shift from using in-house, snowflake, niche container solutions to develop and build components, to the emergence of industry standards, mostly around Kubernetes, and using industry-recognized platforms for large scale container environments. From the roots of containers appealing mostly to developers, customers are now looking for functionality around microservices and containers with more emphasis on the Operations side. This evolution is in a similar trajectory to the way more robust out-of-the-box features were introduced to public clouds. For example: How do I make my containers more secure? How to I support ACID with containers? How do I make it scale up or down automatically? How do I monitor this? Rather than having to rely on ad-hoc custom-built solutions, customers now expect these features to be built into the Container platform of their choice.
In addition, for large enterprises in particular, we see a need to support the deployment and orchestration of container-based application as an integrated part of their overall software delivery strategy, processes and tooling.
A key challenge for these organizations is coordinating and incorporating containers and – with their dedicated tooling, deployment processes and cloud environments – with their traditional releases and overall delivery pipelines and large-scale infrastructure. Large enterprises today operate in a ‘hyper-hybrid’ state, which compounds the complexity that they operate in: having to support microservices and monolithic applications; on-premise data centers AND Cloud/VMs, alongside native Container environments; CD-type releases AND traditional release pipelines. In addition, since the containers and microservices market is still emerging, we see customers experimenting a lot with running containers across multiple environments, or using different cluster orchestration tools and APIs.
In order to manage these complexities and minimize risks, enterprises need the ability to manage containers and microservices throughout the software delivery lifecycle, without risking lock-in to a specific Cloud vendor or point-tool; having to invest a lot of work (and steep learning curve) in rewriting complex scripting in order to re-purpose their deployment or release processes to fit a new environment or tool; or silo-ing their containers development and deployment from the rest of their release practices.
We now need seamless integration and portability across environments/clouds, as well as to enable re-use of our application models and processes regardless of the target (VMs or Containers), without requiring us to refactor our entire pipeline and all processes.
Q: Which programming languages, frameworks, and tools do you, or your company use, to orchestrate and deploy containers?
A: Spring Boot has made a nice way to put together runnable applications on the Java stack by using the right dependencies. It removes a lot of boilerplate code from bootstrapping the application. It helps make the application as small as it can be.
Q: How has the orchestration and deployment of containers changed application development?
A: Containers lend itself well to microservices approach (versus a more monolithic application). It is easy to boot up quickly to launch a simple process. This leads to greater benefits as you scale- both from a development standpoint, and also from a release and operations stand point, since you can deploy independent components. This will lead to continued emphasis on microservices or service-based architectures and application design.
Q: What kind of security techniques and tools do you find most effective for orchestrating and deploying containers?
A: It’s changed in the last year. We integrate with Twistlock to secure images. A year ago, security was a concern with containers in their hosted environment – how to keep images separate. This has been addressed now. They’re running on well-known versions of operating systems.
Q: What are some real-world problems being solved by the orchestration and deployment of containers?
A: We worked with a healthcare company with separate teams doing development and testing and another team running the infrastructure and the pipeline. Containers, and the microservices-based architecture where teams are aligned around a service, now means they all have to work together to know the OS kernel that’s running, how is the code developed/tested, how it can be run on compatible configurations and operationalized moving forward. It’s a great way to align teams around a common goal and service, and make sure that the folks that build it also know how to make it run.
Q: What are the most common issues you see affecting the orchestration and deployment of containers?
A: Wrapping your head around the registry and where you get the containers from. It’s very much like what we’ve done with other binary repositories. You’re moving the entire process around with dependencies. There are meta configuration you need to pass along. Services discovery and binding to do. You must do that for every single process since there’s no local host. Another challenge is stateful applications on Containers- how to ensure ACID, how to monitor for transactions in-flight, how to support larger data stores, etc.
Q: Do you have any concerns regarding the current state of orchestrating and deploying containers?
A: Not really. The industry as a whole has done a good job with the APIs that have straightforward mapping. It can be easy at times, though, to build images and make them too big by failing to realize how many layers you’ve put on top of each other.
Q: What’s the future for containers from your point of view - where do the greatest opportunities lie?
A: There’s still speed and efficiency to be rung out of the application. I’m waiting to see what’s next after microservices and containers. Perhaps its serverless with the lambda functionality offered by AWS and Azure. Hosting constraints are putting us very close to a serverless environment.
Q: What do developers need to keep in mind when working on orchestrating and deploying containers?
A: It’s good for low overhead small process stuff, not monolithic applications. The onus is more on the architect than the developer. Get with the architect earlier in the development process. Application architecture can prevent the adoption of all sorts of new processes and technologies. Start working with architects early to ensure a good outcome for everyone.
Opinions expressed by DZone contributors are their own.