5 Replies Latest reply on Feb 4, 2018 2:02 PM by JoydeeptaBh

    Are You Open to Containers?

    Bob Rhubart-Oracle

      containers_1280.pngThe topic of containers has permeated IT conversations to the point that it is practically unavoidable. So it's about time to explore the subject at a community level to determine where the talk stops and the real work begins. So, a few questions for you:

       

      • How much of your work now involves containers?
      • To what degree has that changed?
      • What was the motivation for the adoption of containers?
      • What tools/technologies do you use in your work with containers?
      • If you are not yet working with containers, do you plan to at some point?

       

      Your responses to these questions --and any additional comments you care to add -- will form the basis for an upcoming article in Oracle Magazine. Some responses may be quoted directly, in which case the quotes will be fully attributed so you can tell your friends, "Hey, I'm in Oracle Magazine!"

       

      Please post your responses by Tuesday September 5. That gives you two weeks (and for those of you in the US the entire Labor Day weekend) to respond.

        • 1. Re: Are You Open to Containers?
          Maarten Smeets

          I worked with containers in workshop setting (Docker is the de-facto standard I think) but not yet at customers. The reason is that most customers I currently work with, implement application servers or database bound integration platforms. Both are not the most suitable match for containerization. Also they often already have a complete virtualization solution in place instead of partial like is the case with containers. This change would require a serious investment and not all customers are willing to make that investment on short term. For the future I think this will change because of drawbacks of the current way of working and benefits of using containers:

           

          Challenges with the current way of working. Especially in large scale application server implementations

          • Difficulties in providing large scale implementations when using application servers. Clustering can become complex. Not only on application server level but also on application level since it often needs to be specifically implemented. Next to clustering we also have the challenge of thread management which is a specific area of expertise.
          • Level of virtualization. Often complete virtualization is implemented such as Oracle VM or VMWare products instead of virtualization by using containers.
          • Stateful. Application servers are not stateless and often contain specific configuration or deployments which makes it difficult to automatically provision, scale up and scale down when required. For example SOA Suite. I often see environments which have grown historically / not by automated fashion. It can be challenging to reproduce those without large investments in automation of installations.
          • Availability. Not all issues can be resolved while the system keeps running. Examples are specific patches and some stuck threads. Sometimes the entire environment needs to be restarted in order to fix these. This means all services which are hosted on the platform will go down. There are ways around this, but those are again specific (e.g. different per application, per application server, per database).

           

          Of course in the OPC this is largely automated in various PaaS offerings which takes the burden of the operations department.

           

          Benefits of using microservices in containers. Containers provide most additional value when developing microservices which can be run stateless inside in an isolated environment.

          • This allows for easy (often technology independent) scaling (increase or decrease the number of running containers hosting the same service). See for example the Application Container Cloud Service features.
          • Provides better levels of robustness. If one container crashes, another one can be started automatically
          • Allows easy upgrading of services by for example providing rolling upgrades
          • It is more hardware efficient since less is virtualized (no hardware and OS virtualization)
          • It allows for more efficient continuous delivery since containers as a whole can be promoted through DTAP environments. promotion of VM's through environments is something I've not seen happen
          • Within a container, developers have more control on what to install and do not require the operations department for every little thing. Especially in large organizations where operations capacity is limiting, this can be a major driver for developers to push working with containers.

           

          An additional benefit is that for example Node.js is very suitable to create microservices in. JavaScript which is currently mostly used by front-end developers, can be used in microservices in the middleware and backend layer. This makes the JavaScript skill useful for different layers in the stack and also makes it possible to reduce the amount of translations/layers which have to be made to go from front-end to back-end. This in turn reduces development effort, makes management of environments easier and helps optimize performance.

          1 person found this helpful
          • 2. Re: Are You Open to Containers?
            Frank Munz
            • How much of your work now involves containers?

            I worked on two projects that use containers in production. Both are cloud native projects. Both use Docker. None of them ever faced any container specific issues.

             

            • What was the motivation for the adoption of containers?

            In one project the decision for Docker was taken simply because it seemed to be part of a modern development stack and at the end it turned out to be a great fit. In the other project there was a major concern about the vendor lock-in with a particular cloud provider and therefore the decision for Docker was obvious.

             

            • What tools/technologies do you use in your work with containers?

            There is a lot of talk about Kubernetes these days because it's widely understood that there is more to it than just running a single Docker container.

            However, most DevOps vastly underestimate the complexity of operating such a Kubernetes cluster in production. Companies which are not at a hyperscale will therefore often go for a simpler container cloud service (PaaS) such as OCCS or ECS (or even use the built-in Docker Swarm instead, when running on-premises).

            • 3. Re: Are You Open to Containers?
              Lucas Jellema

              Containers have been a catalyst for my thinking about application and platform architectures. The importance of stateless applications in order to allow horizontal scalability and easy failover is a drastic shift from the heavy session oriented server side web applications of the past 15 years; working with and thinking about containers strongly influenced me. As it also did with regard to serverless computing – the next paradigm shift that takes functions and the events that trigger execution of those functions as a starting point – and considers the infrastructure as a dynamic pool of execution engines for instances of those functions. It sounds a little abstract I realize – it will mean that we will leverage infrastructure resources even more flexibly, scalable and efficiently, without allocating compute resources for an application that does not constantly utilize those resources.

               

              Microservices have only become a serious option because of containers – even though containers may not even be used for all implementations of microservices. And of course DevOps: to make a team responsible for the full life cycle of their application component (or: microservices) – from Development to 24/7 operations – they need to control both application and platform. Only by making the platform part of the deliverables that move in Continuous Delivery from development to production can that responsibility be taken in a fast moving, agile environment. Containers are a perfect vehicle for bundling application and [application specific aspects of the] platform.

               

              On a very practical level have containers enabled me to better organize and utilize the laptop I use for R&D. I used to quickly make a mess of my laptop with new tools, platforms and frameworks I was experimenting with . Then I tried using Virtual Machines – which was an improvement – however a laptop only has so much memory and hard disk. Besides, I had to compose most VMs myself. Containers are lightweight, can easily be shared with colleagues and are simply available, ready to use, for most popular technologies, saving me lots of time and anguish. Note: The soon to be released CRIU feature in Docker will allow us to very rapidly create snapshots of running containers including their memory state. The possibilities introduced by CRIU are very interesting indeed. (see for example: https://yipee.io/2017/06/saving-and-restoring-container-state-with-criu/ ).

               

              Another upcoming usage for containers is for automated and manual testing: containers can quickly be started with the starting point for a test. The test can rely on that start situation – in terms of the business data already available – and is free to muck around. Once the test is completed, the container is simply discarded and a fresh one started for the next test. This is the easiest way to manage a clean test base environment.

              • 4. Re: Are You Open to Containers?
                A. Chatziantoniou
                • How much of your work now involves containers?

                 

                At one of my customers this is the underlying technology for some (front-end) improvements - a drive to get away from WebCenter Portal.

                 

                • To what degree has that changed?

                 

                This organization is not a fast adopter, so I am still stuck between the old and the new world.

                 

                • What was the motivation for the adoption of containers?

                 

                Frankly - the decision was more influenced by some frustration of current Oracle products and support.

                It has a large PoC attitude and one still needs to see if this work out.

                 

                • What tools/technologies do you use in your work with containers?

                 

                Docker, Docker Swarm - some Kubernetes.

                 

                 

                Some general remarks from my side - use them in an overview manner. They are depicting doomsday scenarios - but when rewritten they can be used as guidelines.

                 

                I believe that the operations side will have a tough time to cope with containers. A number of organizations I have encountered are already resource-stretched when it comes to the handling of "normal" Oracle infrastructures. With containers they will face a completely different level of complexity. One still needs to figure out if the tools support is enterprise-ready.

                 

                The talk of the town is microservices - but there are two issues I see when moving away from a suite-like approach.

                 

                a) Variety: as each microservice deals with ist own problem-domain you will need a very strong governance process for development. If not you will end up with a multitude of coding strategies, approach to data handling and so on. I am afraid that with the abandoning of a suite-model and the use of small independent problem-domains each development (or shall I say DevOps) team will invent their own version of the wheel.

                 

                b) Operations: currently development teams are in separate units than an operations team. When they merge into DevOps and focus on containers and microservices they might loose the overall picture. If my piece is working fine then the fault lies with somebody else. Now this invites cascading errors to happen. Especially with large organizations this will be an operational nightmare.

                • 5. Re: Are You Open to Containers?
                  JoydeeptaBh

                  Hi ,

                   

                  It's interesting to note that containers being promoted here in community. I would like to know about the docker image in linux with soa suite 12.2.1 and it's authentic link and documentation with any limitations. I would like to use for hosting my customers services (soa/osb) and make autonomous cd management SOA IntegrationCoherence