devopsy.kinsta.cloud

Tag: containers

  • DevOps, ITOps and PaaS: What do you think?

    DevOps, ITOps and PaaS: What do you think?

    We are very happy to announce that we have launched a new survey that will explore how the community feels about DevOps, ITOps and PaaS. The survey is another in the continuing surveys we are conducting to help all of us understand more about how DevOps is really influencing how development, Ops and IT are being changed.

    This survey is sponsored by Apcera, makers of the Apcera Hybrid Cloud OS. The survey is only about 19 questions and shouldn’t take more than 5 minutes. It is aimed at understanding if there is a difference in opinion of who is leading innovation and where are the roadblocks to that innovation in organizations. It also seeks to understand what are organizations are thinking about containers and specifically are different parts of the IT team looking at containers differently.  Finally, the survey tries to help us understand what are the attitudes towards PaaS.

    As we always do we will release the survey findings when complete. You are helping not only your own organization but the entire DevOps community if you would take a few minutes to take the survey right now we would be very grateful. If there is something you think we got wrong on the survey or left out, please let us know by commenting here.

    If you are interested in hearing more about Apcera and how it looks at containers and PaaS you should check out our Q & A with their CEO over on Container Journal.

    BTW stay tuned as next week we will release the results of our last survey, The Real Value of DevOps.

  • 4 big challenges of microservices

    4 big challenges of microservices

    The rise of microservices as a means of developing and delivering software value faster is clearly on the rise. Containers have skyrocketed from a fringe technology to a mainstream imperative and organizations are scrambling to jump on the microservices bandwagon. Before you rush out to embrace microservices, though, there are a few things you should keep in mind.

    First let’s talk about what microservices even are since it’s a relatively new term in a sea of relatively new terms.

    Al Hilwa, research director, Application Development Software at IDC described microservices this way:

    “Microservices is an architectural approach that draws on long evolving experience in software engineering and system design, including the SOA efforts of the last two decades. Microservices architecture is enabled by a spectrum of tool categories but is primarily an architectural approach to system design that also requires considerable organizational and cultural adjustment to execute successfully.”

    Put more succinctly, microservices is an evolution of software development and deployment that embraces DevOps and containers and breaks applications down to smaller individual components. Organizations can develop and deploy faster because there is a modular approach that makes code more efficient and enables much of the common or routine elements to be automated.

    Everyone seems to be doing DevOps and containers these days. If you’re not you may feel like you need to catch up quick or risk being left in your competitors’ collective dust. That may be true to some extent, but you have to approach microservices in the right way and for the right reasons. Jinesh Parekh, CEO of Idyllic Software, shared some thoughts about four challenges organizations should consider when venturing into the world of microservices.

    1. Insufficient guidance

    When it comes to implementing new technologies and embracing new strategies it can be a little like the “Wild West”. There are few hard rules in place and very little in the way of guidelines or documentation to help you navigate how to build and deploy software using microservices. Thankfully, sites like devopsy.kinsta.cloud and ContainerJournal are here to provide as much information as possible to give organizations some guidance.

    2. Getting it wrong

    There are a variety of “moving parts” involved in doing microservices successfully. Your organization should adopt a DevOps culture and have the appropriate infrastructure in place to avoid getting it wrong. Microservices architecture is generally built on a foundation of cloud and virtualization, and relies heavily on automation to ensure success and avoid failures.

    3. No going back

    You should be aware that it’s exceptionally difficult to switch back once you start down the microservices path. The changes that have to happen in terms of culture, tools, and processes to embrace microservices are not easily undone. The good news is that there is very little—if any—reason an organization would move to DevOps and containers as a development framework and then decide to revert to the old, monolithic way of doing things.

    4. Deliver value

    Parekh’s focus on delivering value is biased toward Idyllic Software. His company is in the business of delivering applications for clients via microservices and Parekh suggests that organizations outsource development to an experienced leader to ensure microservices meets expectations. You don’t necessarily have to outsource to Idyllic Software, though, or outsource at all. You just need to make sure that your approach to microservices benefits your organization—that it adds value and meshes with business objectives and isn’t just microservices for the sake of following the microservices trend.

    Microservices seems to be here to stay, and seems to be on the same path as DevOps and containers from niche concept to mainstream business adoption. As you ramp up to jump on the microservices bandwagon just make sure you keep these things in mind.

  • Microsoft and Docker provide progress report on Docker for Windows Server

    Microsoft and Docker provide progress report on Docker for Windows Server

    In the fall of 2014 Microsoft and Docker unveiled a new partnership—a commitment to work together to bring native support for Docker containers to the next major release of Windows Server. Earlier this week the two talked about the progress made so far and gave some clues to what customers should expect once the next Windows Server hits the street sometime in 2016.

    Mark Russinovich, CTO of Microsoft Azure, was in San Francisco this week at Docker headquarters meeting with his counterpart, Docker founder and CTO Solomon Hykes. The two met to talk about how their collaboration is progressing to bring Docker containers to Windows Server. The two didn’t share many specifics, but did say that the effort so far is achieving established goals and is proceeding according to the schedule they’ve laid out.

    What is that schedule? We don’t really know. All Russinovich or Microsoft will commit to officially at this point is 2016. Whenever it arrives, though, it will represent a significant step forward in creating a platform-agnostic environment for developers. Windows developers will be able to integrate Docker containers natively with Windows Server, Visual Studio, and .NET applications.

    The CTOs clarified that Docker support in Windows Server won’t allow Linux applications to run on a Windows operating system. Likewise, Windows applications in Docker containers won’t run on Linux. The value of the partnership and the integration of Docker support in Windows server is that developers will be able to leverage the same tools and common platforms for deploying, running, and managing the Docker container environment.

    Microsoft Azure already added support for running Docker containers on Linux servers within the cloud platform. Once the new Windows Server hits, organizations will be able to run Docker containers on Linux or Windows and manage it all through Azure. It also enables developers to create application services running on opposing platforms and run it as part of a distributed application spanning both Windows and Linux.

    The advantage from a Windows developer point of view is the ability to use the tools they’re familiar with. Developers will be able to use Visual Studio and .NET along with the built-in collaboration and workflow tools, as well as debugging and source-code control. It allows organizations to employ existing development practices and tools for creating and deploying Docker containers.

    From a DevOps perspective the integration of Docker containers natively with Windows Server will enable better automation and continuity. DevOps and containers result in frequent changes to the app code and the underlying infrastructure, which is a bit of a culture shock for both traditional developers and traditional IT admins. Straddling the line between the two worlds by incorporating Docker containers and DevOps tools with the familiar Microsoft development platforms organizations are comfortable with takes some of the pain out of that cultural evolution.

    Ultimately, the partnership between Docker and Microsoft will lay the foundation for completely platform-agnostic development. The app containers themselves may still require a specific OS to run, but at an organizational level the environment and infrastructure can be viewed and maintained as a holistic whole.

  • DevOpsQA NJ Meetup – Containers with Joyent

    DevOpsQA NJ Meetup – Containers with Joyent

    DeIMG_2381vOpsQA NJ just held our July Meetup on Containers with Casey Bisson from Joyent and Jeremy Rampon from Syncsort as speakers.   The meetup was held at a new ROKITT location,  a state-of-the-art office space with breathtaking views of NYC.   This session marked 1 year since our Meetup was formed in July of 2014 and it was great to celebrate it with a great group of fellow DevOps and Automation enthusiasts.

    Jeremy RIMG_2387ampon gave a great introduction to Docker and container technology.  He spoke about how Docker allows to build, ship and run any app, anywhere with almost no overhead.  We also discussed how Container technology is different from VM and future plans of Docker on Windows.

    Casey Bisson gave a bIMG_2386rief overview of the Joyent technology which offers container native infrastructure that runs in public and private cloud.  We all want to run Docker on bare metal, but don’t want to lose security and elasticity.  Joyent provides a way to do this without the overhead attributed to VMs.  The Triton Elastic Container Infrastructure is build on top of SmartOS  and provides its implementation of the Docker API, with full support for the Docker client and related orchestration tools.  The advantages are the ease of management and improved performance from running on bare metal.    We also got a live demo of the software that runs SmartDataCenter (software that runs the Joyent public sloud and powers private clouds) all the way from install to provisioning customer containers.

    At the end of the session we did a raffle for 3 awesome books sponsored by Pearson and then toasted to 1 year Anniversary of DevOpsQA NJ.

    IMG_2390IMG_7272

  • Microservices define the next era of IT

    Microservices define the next era of IT

    There is a lot of focus on DevOps and container technologies these days. Both are very strong trends in IT on their own, but each is also proof of a larger shift in IT culture to a microservices architecture. A new report from IDC titled “The Emergence of Microservices as a New Architectural Approach to Building New Software Systems” takes a closer look at the evolution and impact of microservices.

    Let’s start with the obvious question: What exactly is microservices? “Microservices is an architectural approach that draws on long evolving experience in software engineering and system design, including the SOA efforts of the last two decades,” said Al Hilwa, research director, Application Development Software at IDC. “Microservices architecture is enabled by a spectrum of tools categories but is primarily an architectural approach to system design that also requires considerable organizational and cultural adjustment to execute successfully.”

    Put another way, microservices is an umbrella term that applies to breaking systems and applications down to a more granular, modular level. Containers are an example of taking an application and making it into a self-contained component, and DevOps provides the framework for developing, deploying, and managing the container ecosystem.

    By some interpretations microservices and containers are somewhat synonymous. In other words, microservices is just another way of saying that an organization is using container technologies for app development and deployment. IDC classifies microservices more broadly, saying it is based on an approach to organizing software development—more of a concept and less of an actual product or technology.

    The Wikipedia definition of microservices sums it up like this: “In computing, microservices is a software architecture style, in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs. These services are small, highly decoupled and focus on doing a small task.”

    Although the concept of microservices is broader than the underlying platforms or tools it uses, IDC acknowledges that the advancements in software development and deployment methodologies—namely DevOps and container technologies—has played a pivotal role in elevating microservices to where it is today.

    The transition from a traditional hardware server infrastructure in an on-premise datacenter to a cloud-based, software-defined infrastructure that can be created, modified, or removed programmatically offers significant benefits for organizations. The microservices architecture enables companies to be much more agile and cut costs at the same time.

    There are some challenges and concerns as well, though. Hilwa notes, “Microservices architecture, by its very nature, is distributed and operates across networks and can thus exact significant performance penalties that must be accommodated with architectural solutions, like caching layers and API management and optimization techniques.”

    In the IDC report Hilwa talks about the need for strong organizational support and an overall shift in the IT culture in order to succeed with microservices. As Hilwa puts it, “Organizations have to increase their tolerance for risk and learn to fail gracefully, fast and often in order to achieve success.”

    Hilwa provides a comprehensive overview of the current state of microservices in the report along with some prescriptive guidance for organizations that are either just trying to understand what microservices is, or those that have already waded into microservices but want a better appreciation for the benefits and pitfalls.

  • Webinar: Introducing CloudBees Jenkins Platform – your foundation for DevOps and CD with Docker Containers

    Webinar: Introducing CloudBees Jenkins Platform – your foundation for DevOps and CD with Docker Containers

    Continuous delivery (CD) of applications is rapidly becoming a differentiator in this application economy. CloudBees, the enterprise Jenkins company, recently announced the availability of the CloudBees Jenkins Platform to help organizations adopt CD. This new enterprise offering from CloudBees brings CD to the masses with the new Team Edition, while enabling enterprise CD deployments powered by Jenkins at scale with the Enterprise Edition. At the same time, the Jenkins open source community, in conjunction with CloudBees, released six new plugins to support the use of Docker containers within Jenkins-powered CD and CI processes. Docker is powerful new technology that allows teams focused on delivering software to standardize their development and production application environments for reduced risk and accelerated application delivery. Leveraging Docker containers in a CD process managed by Jenkins is the ultimate way to deliver better software faster.

    Join Tracy from CloudBees as she talks about Cloudbees’ new enterprise offering and the changes happening in the Jenkins community to provide first class support for Docker in the creation of CD pipelines. In this webinar, Tracy will introduce features in the latest release of the CloudBees Jenkins Platform to
    help manage Jenkins’ across the organization and walk through six common delivery patterns with Jenkins and Docker. Tracy will then tie it all together with a demo of an end-to-end delivery pipeline with Docker.

    Continuous delivery with Jenkins and application containerization with Docker are rapidly becoming two of the foundations of the DevOps movement. Check out this webinar to learn how you can adopt these new tools and techniques in your own DevOps transformation.

    Recorded: Wednesday, August 5th, 2015

    Recording

    Slides


    [seoslides embed_id=”3285347f9c95″ script_src=”https://devopsy.kinsta.cloud/embed-script/cloudbees-jenkins/8856/” overview_src=”https://devopsy.kinsta.cloud/slides/cloudbees-jenkins/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”Cloudbees – Jenkins” /]

    Your Host

    alan_new_head_shotAlan Shimel, Editor-in-Chief devopsy.kinsta.cloud, An often-cited personality in the security and technology community and a sought-after speaker at industry and government events, Alan has helped build several successful technology companies by combining a strong business background with a deep knowledge of technology.

     

    About the Panelists

    cuppa (1)Tracy Kennedy is an associate product manager for CloudBees and is based in Richmond, Virginia. Prior to her current role, Tracy has worked at CloudBees as a solutions architect and a developer success engineer. In her free time, she enjoys rock climbing, grand strategy games, and reading. Read more about Tracy in her Meet the Bees blog post and follow her on Twitter.

     

     

     

     

    udaypalUdaypal Aarkoti is the Director of Solution Architecture at CloudBees.  He believes in complete end to end automation and that continuous delivery is the future of application delivery. Prior to CloudBees he lead the middleware solution architecture team at Red Hat.

  • Say hello to Container Journal

    Say hello to Container Journal

    Today we launched a sister site to devopsy.kinsta.cloud – Container Journal. The url for the site is http://www.containerjournal.com. The site is dedicated to spotlighting everything about containers and computing (as opposed to containers like in the Container Store). This includes not only the containers themselves, but everything that goes along with it.  Topics wil include container management, data management for containers, container security, networking for containers – in short the entire container ecosystem.

    Right now most of the content on Container Journal was container related content that was originally on devopsy.kinsta.cloud. However, over time Container Journal will have more and more of its own original content that will not appear here devopsy.kinsta.cloud. So you will need to check Container Journal to stay up on the latest container related content.  A good way of doing that is to sign up for the Container Journal newsletter.

    In addition to articles Container Journal will feature webinars on container related topics, as well as other special features including ebooks and surveys. Many of the outstanding authors who contribute to devopsy.kinsta.cloud will also be writing for Container Journal as well.

    We are looking for good container related content though. If you would like to contribute to Container Journal, write me at editor@devops.com with your request.  We are also seeking sponsors, partners and advertisers for Container Journal as well.  In a relatively short time, we think Container Journal will be largest media site with a dedicated collection of container related content.  This is your chance to be part of it. Sponsor info can be had at sponsor@devops.com.

    Also be sure to check out the Daily Poll on Container Journal. We will be asking some great questions with rapid feedback on what others are saying.

    Like any new venture, I am sure there will be growing pains with Container Journal. Please keep me posted if you notice anything.

  • ElasticBox enhances Container support with new release

    ElasticBox enhances Container support with new release

    ElasticBox announced a new version of their product today that enhances Container support. In yet another example of how important Containers are becoming to today’s software development scene, ElasticBox will now allow you to define microservices as Docker files in containers.

    Other enhancements include (from the press release) :

    UI Enhancement: Tags now make it easier to sort and find items quickly throughout the product. The rich interface enables IT Ops and Development teams to visually assess the latest status of instances, share and manage boxes, and collaborate easily.

    Deployment Policies:  New functionality allows policies to be boxes, enabling customers to share virtual infrastructure resources from providers like AWS (Amazon Web Services) without having to expose AWS account specifics. Policies have claims that enable IT Ops to tag virtual machine properties, such as platform, instance type, OS family and more. Like all boxes, these deployment policies are reusable and sharable.

    Script Boxes: Script boxes are powerful building blocks that can be shared and reused. Variables and script events are stored here. With the addition of requirements, Script boxes have tags to identify the platform, runtime and infrastructure dependencies of the box. At the time of deployment, the requirements and policy claims can be easily married, so developers can self-service the appropriate infrastructure, and IT Ops has the reassurance that the right infrastructure resources are being consumed.

    Automatic Updates: With semantic versioning of boxes, customers can now choose automatic updates for major, minor and patches of instances. This enables rapid, efficient updates at scale for enterprises.

    Enhanced Container Support: As more customers experiment and deploy to containers, ElasticBox can now support containers, such as Docker, as a new box type. This enables enterprises to define microservices as Dockerfiles in containers, which then can be linked via bindings. With this enhancement, the lifecycle of application services can be easily managed.

    vCloud Air and vCloud Director Support: ElasticBox supports a multitude of private and public cloud infrastructure providers. Enterprises with VMWare’s vCloud Air or vCloud Director workloads can now leverage ElasticBox for complete workload automation. At deploy time, ElasticBox auto provisions vApps, one template per VM, and orchestrates automation.

    I had a chance to speak with Carol Carpenter, CEO of ElasticBox on the new release:

    Q. Why is this latest release so important?

    As DevOps matures, we see that companies seek to not only provision applications faster but reduce inter-dependencies between development, QA, and IT Ops. Kill the cruft in the application cycle.

     This latest release of ElasticBox brings deployment policies for DevOps to retain needed control and visibility while enhanced container support delivers more flexibility to application teams.

    Q. What’s changed?

    Many enterprises have built their application deployment workflows around a handcrafted potpourri of tools and processes. When faced with scale challenges from the business, existing tools are fragile and expensive in terms of failed builds and troubleshooting time. ElasticBox brings an adaptive off-the-shelf management solution so enterprises can spend less time re-tooling and more time shipping code.

    Q. What’s next?

    ElasticBox is built by developers who want to ship code faster to the cloud, and we’re committed to this mission. We’ll continue to ensure our platform adapts to customers’ evolving environments, regardless of which technologies they choose for their development and operational stack.

    More information on the new release can be gleaned from ElasticBox CTO Alberto Arias Maestro’s blog.

    devopsy.kinsta.cloud is working with ElasticBox on a new DevOps survey right now. You can take the survey and win an Amazon Gift Card or 3dr Drone by taking the survey here.

  • OCP is a victory for CoreOS and Containers in general

    OCP is a victory for CoreOS and Containers in general

    A broad coalition of major tech companies have joined forces to create the Open Container Project—or OCP. The move to develop and maintain common standards around software containers vindicates the CoreOS split from Docker and reunites the two in a common cause that will make all container platforms and technologies stronger.

    A press release announcing the Open Container Project explains the overall vision for OCP. “Housed under the Linux Foundation, the OCP’s mission is to enable users and companies to continue to innovate and develop container-based solutions, with confidence that their pre-existing development efforts will be protected and without industry fragmentation.”

    Docker and CoreOS are at the heart of OCP but they’re by no means alone. A veritable “Who’s Who” of DevOps and container technologies has enlisted to support OCP, including Amazon Web Services, Cisco, EMC, Google, HP, IBM, Linux Foundation, Microsoft, Red Hat, and VMware.

    At one point Docker had a Standard Container Manifesto that spelled out some basic attributes it felt all containers should have. The Standard Container Manifesto called for containers to operate in a standard fashion, be content agnostic, infrastructure agnostic, and designed for automation among other things. When Docker removed the manifesto and seemed to shift to a more proprietary strategy CoreOS split off and launched its own container technology to continue the vision of a container standard.

    “An open, well-defined specification is required for the overall success and adoption of containers. At CoreOS, when we started the App Container spec (appc) our goal was to have a well-designed software container specification. With the OCP, we have now come together with Docker and many industry giants in an effort to unify this goal.”

    The launch of OCP and the laundry list of companies backing it show that CoreOS was not alone in its pursuit of the vision for a container standard. “We are excited to support this effort to bring the industry together to agree on a core standard for containers, which we feel will benefit all customers no matter what cloud provider they use,” said Jason Zander, CVP, Microsoft Azure. “Through our close work with Docker over the last year we have demonstrated our commitment to openness and welcome this opportunity to help create an open platform for customers.”

    “Customers need an open, interoperable future for software containers and we are happy to see the industry coming together to establish a common standard,” explained Kit Colbert, vice president and CTO, Cloud-Native Applications, VMware. “Our participation in the Open Container Project reinforces our goal to help customers innovate more rapidly and benefit from containers as they adopt the technology in their environments. We look forward to working with the community on container portability and security which are areas of focus for enterprise IT.”

    According to the OCP press release Docker will donate the code for its software container format and runtime—as well as the associated specifications—to the project. The leadership team from the Application Container spec (appc) will also contribute technical leadership and support for OCP.

    Ben Golub, CEO of Docker, summed up by acknowledging the effort and support for OCP. “We’d like to thank the many people in the industry who came together to support this important initiative. Our thanks to the Linux Foundation for the incredible work they have done in helping to pull this broad group together. Given the criticality of the intersection of containers and operating systems, we’d also like to thank Red Hat and Microsoft for their early leadership on this initiative. Our sincere appreciation to IBM and Intel for their ongoing encouragement of open governance. Finally, we’d like to recognize the members of the appc community, including Google and CoreOS, for their willingness to join all of us to constructively address these critical issues.”

    Now that all of the major players are united in a common cause to define and maintain an industry standard for containers it will be much easier for developers and organizations to embrace container technologies without reservation. The confidence that your investment of time, money, and effort won’t be wasted or paint you into a corner is very liberating.

  • Two paths to metal devops: cloud-like API driven & cluster building

    Two paths to metal devops: cloud-like API driven & cluster building

    I’ve been seeing a rising interest in metal DevOps fueled by containers and scale-out data center platforms (like Hadoop, Ceph & OpenStack) that run at the metal level. While I see this is a growing general trend (Packet, Internap, RackSpace, OpenStack Ironic, MaaS), I’m going to stay firmly within my wheelhouse and use OpenCrowbar as my reference here.

    Building on the API-driven metal features of OpenCrowbar, this has translated into two paths for workloads to run on metal:

    1) “Cloudify” the metal using APIs from tools like Chef Provision, SaltStack Libcloud, Docker Machine, Cloud Foundry BOSH. These tools have clients that target cloud APIs like OpenStack and Amazon. These same clients work against cloud are easily ported to Crowbar’s APIs.  Five years ago, conventional wisdom was that we’d need a universal cloud API; however, practice has shown it’s not very difficult to wrap APIs in a way that does not reduce every cloud to a least common denominator.

    2) DevOps deploy the workload using hand-offs to tools like Chef, Saltstack, Puppet or Ansible. This approach leverages the community scripts (Cookbooks, Modules, Playbooks) for the workload with the critical ability to create a tuned environment and inject the needed parameters directly into the scripts.  A critical lesson we learned going from Crowbar v1 to v2 was for our scripts to have crisp attribute input/output boundary to avoid embedding environmental knowledge into the code.

    While I’m casting this in Crowbar terms, I see this approach to metal as coming into the market by force fuels by a desire for containers-on-metal and devops-on-metal.

    Let’s look at some of the unique and shared use-cases for each approach:

    Metal API

    		 Both

    Metal Cluster
    • Easy Cloud to Metal Migration
    • Minimal Tool Customization
    • Portability of DevOps Scripts
    • Take advantage of power cycling
    • Enables constant refresh cycles
    • Leverage Hardware features
    • Advanced Network topologies

    In either case, you have to handle bespoke (hipster word for custom) steps in the provisioning flow that are unique to the your operational needs. Our experience is that each site (even each server!) is unique in some incremental way.  For example, one site may require teamed networks with VLANs while another requires flat networks with an SDN layer.

    These differences are not mistakes or errors: the reality of physical ops and individual operational choices mean that there are a lot of valid configurations. Rather than attempt the Sisyphean task of enforced conformity, we work to abstract differences so that they can be ignored when they are not material.

    In the end, the choices are not mutually exclusive. Metal APIs are often faster but harder to optimize. You can use them to get started quickly and then invest time to optimize a cluster for long term operations. The underlying physical orchestration can support both.

    Are you looking at getting closer to metal?  Which of the options above makes the most sense to you?  I’d love to hear about your use-cases, architecture and configuration requirements.