Tag: elasticbox

  • DevOps Chat: Carol Carpenter, CEO ElasticBox on the Real Value of DevOps

    DevOps Chat: Carol Carpenter, CEO ElasticBox on the Real Value of DevOps

    Carol-93I recently sat down with Carol Carpenter, CEO of ElasticBox.  We just released the results of the survey we partnered on with ElaticBox on the “Real Value of DevOps”.  There were some great takeaways in this survey for leaders looking to lead the transformation in DevOps.  Carol and I discussed these takeaways and other relevant topics.  Below is the streaming MP3 file, as well as the transcript of our conversation below that.

    [soundcloud url=”https://api.soundcloud.com/tracks/227014073″ params=”color=ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false” width=”100%” height=”166″ iframe=”true” /]

     

    Alan Shimel:                Hi. This is Alan Shimel, and this is another DevOps Chat for the Leadership Suite, at DevOps dot com. Thank you for joining in. Our guest today is Carol Carpenter, CEO of Elastic Box. Carol, welcome to DevOps Chats.

    Carol Carpenter:        Thank you Alan. It’s great to be here.

    Alan Shimel:                So Carol, well, you and I know each other, but for our audience, just quickly, just in case they’re not familiar with Elastic Box, can you give us a little background?

    Carol Carpenter:        Sure. So Elastic Box is a cloud application manager. We enable companies to deploy any application through any infrastructure, or private or public cloud, so that businesses can actually deliver code faster. We help companies, like Netflix, T&A, Cytobank and more orchestrate the deployment and management of applications.

    And many of these companies have seen their application life cycles increase by 10X, in terms of speed, and time to deploy, and time to market. And the secret sauce of in terms of speed Elastic Box is our reusability. And the way we orchestrate is through a reusable architecture of, what we call, boxes that enable IT operations, dev-ops, and even end user’s application, for supervision on demand, infrastructure in one click, and access to a sophisticated service catalog.

    Alan Shimel:                Fantastic. And Carol, we just recently announced you had sponsored a survey that we did here at DevOps dot com, with some research, on the real value of DevOps. And, of course, people can download the survey from the Elastic Box site, and read about it here on DevOps dot com.

    But I wanted to ask you, what as the reasoning behind doing some survey research?

    Carol Carpenter:        Well, you know, there’s a lot of discussion about dev-ops. We’re seeing many new titles and organizations recruiting for dev-ops, and yet when we would talk to customers and prospects, there was still ambiguity about the role itself – who’s actually doing what?

    And what is the real value of the investment – both in terms of people, time – open source or not? Where is the real value in return on those investments? And we wanted to try to understand, and delve into that area, and understand better – what’s really happening in dev-ops? Who is spending this time there? And what’s the ROI?

    Alan Shimel:                And Carol, for these DevOps Chat for the Leadership Suite, we’re really talking to CIOs, CTOs, VPs – upper management. What, if you can, as a CEO yourself, what would you say were some of the biggest or most important takeaways for leaders within the survey?

    Carol Carpenter:        Alan, great question. You know there were a few key takeaways, and I think you and I were both surprised by a few of them. I think, to start with, as a leader you look at what are we investing? How are we spending our money? And what is our return?

    The ROI analysis I think is still very early and immature around dev-ops, and we have lots of hypotheses about that. But it was surprising because there has been a lot of effort, and energy, and investment that’s gone into dev-ops tools. I mean – look at how many dev-ops vendors there are right now in the market.

    And yet, the actual impact and measurability remains largely subjective and I don’t know – over 50 to 60 percent of the respondents said, I don’t know, when asked about Hoover Trucks. That as like the big, number one insight, that surprised me.

    I think some of the other takeaways are a little bit less surprising, but nonetheless reinforcing of what’s happening in dev-ops today. So number one, when we asked about the team sizes and functions, Alan, what we saw is that, dev-ops, while over 50 percent of the respondents said – yeah, dev-ops is my primary function.

    You know another 41 percent said they had another title, and it was IT Ops. And then another 42 percent said their secondary function is around security, and that’s pretty interesting. But what it reminds us is that dev-ops is still a very nascent, growing area, and that these people are wearing lots of hats.

    And so we, as a vendor partner to dev-ops teams and others who are trying to work with them, you realize like they are spread very thin, and that dev-ops teams are being asked to do work that – what used to be traditional IT Ops, in addition to work that’s now kind of develop or deployment work, and be this communication bridge across these different groups.

    Alan Shimel:                I agree. I mean, Carol – and you and I have gone over the survey in-depth, obviously. To me, the biggest takeaway from leadership is what you hit on first, which is – we really don’t know the true ROI yet of a lot of these dev-ops practices, and tools, and patterns if you will.

    I think, gut, right – and so many executives, as you know, Carol, go with their gut, right? And if their gut tells them that automation is good, that dev-ops can help, that more releases, higher-functioning IT directly results in higher profits, and higher productivity.

    And so they’re going on their gut, and they’re going on what seems logical. But a lot of people just haven’t done the – the bean counters haven’t jumped in there yet and done the real statistical analysis, to really show us – yes. This is the ROI. Yes. This is the return where you’re going to get it, and this is how much more profitable.

    We’ve seen people sort of bite at the edges, if you will. But from a leadership point of view, especially in more risk adverse verticals, I’m surprised more people haven’t asked that. The other thing that I thought, Carol, from a leader’s perspective as really something to keep in mind was, so many – and I think it’s a fallacy.

    So many people think of, open source, as free. Yes, you don’t pay for the software, but when you look at the total cost of ownership, it’s not free. It may be cheaper than commercial software and maybe not. I’ve seen studies go both ways. But I think, from a leader’s point of view, they have to remember that just because we’re using open source “free” software doesn’t mean that it’s free throughout the total life cycle of it. Make sense?
    Carol Carpenter:        Oh yeah. I absolutely saw that in _____ as well, and I think the other point, as a leader looking at dev-ops and what kind of investments you make – I think the promise of dev-ops is to reduce the silo between development and operation cycles. That’s how the title emerged.

    And yet, one of the findings is around dev-ops tools lacking sufficient integration for the end to end delivery and ongoing management. And so I think what we’ve seen is – yes, great pockets of success in automating one portion of the pipeline.

    And we saw a large number of those comments are doing automated testing around continuous integration, and continuous delivery. But what you’re seeing is – while that’s working is – across the whole end-to-end tool chain, like there still are these little silos. And I think what we will see evolve over the next coming year, is more integration, more glue in terms of platforms, to bring them together, in these various dev-ops projects.

    Alan Shimel:                I think you’re dead on Carol. I think what we’re seeing right now is the first generation of dev-ops tools, making their way into the marketplace, and they themselves are almost siloed, right, where they don’t necessarily work with each other.

    Carol Carpenter:        That’s right. I mean what we saw was, when people were looking at their investments and their responses in the surveys – all right. There’s _____ control. There’s container platforms. There’s CICD. They’ve invested a lot in configuration management, and there’s automated tools for that, and some people have invested in it.

    And it’s still disparate, so I agree with you. I think we’re going to see continued maturation of this market.

    Alan Shimel:                Yeah. I think you’ll see a second generation of tools that maybe seek to stitch together a lot of these first-gen tools and, frankly, that’s somewhere where Elastic Box plays too, right?

    Carol Carpenter:        Absolutely. We like to think of ourselves, Elastic Box, as elastic glue. We’re the glue to bring together a lot of these dev-ops initiatives into an end-to-end integrated delivery and management platform.

    Alan Shimel:           Absolutely. Carol, so we talked that there were a lot of surprises or things that we didn’t expect in the survey. What would you say was the biggest surprise for you?

    Carol Carpenter:        Well, I think that the biggest surprise was around the lack of measurability and lack of understanding the ROI of the dev-ops investments, either in terms of people, time, resources, or money. And I’d say the second one is that when we asked about the dev-ops tools that they are using, that CICD came to the very top.

    And, on the one hand, you could say – okay. That’s not a surprise. People have been trying to automate testing for a long time. But CICD is a step beyond that, and that was surprising to me that that’s the biggest driver still. I guess, based upon the noise and what we hear every day in the market, I expected that there would have been another dev-ops initiative would have risen to the top, such as, you know [Crosstalk] –

    Alan Shimel:                Like configuration management?

    Carol Carpenter:        Management or monitoring, which obviously there’s very, very strong monitoring tools, or security and compliance, or even containerization. And maybe it’s because of the press and media and we’re so bombarded by a lot of the initiatives, that we think that that’s where the money is going, and where people are spending time and energy.

    And yet, automated deployment and testing and CICD are still at the top.

    Alan Shimel:                Absolutely, and I think – I mean, what we see here at DevOps dot com bears it out. Look, there’s money being spent across the board in dev-ops tool sets right now, but CICD certainly are some of the biggest ones. Carol, believe it or not, we’ve already gone over 12 minutes, and we try to keep these short, and we need to wrap it up.  But I wanted to ask you the same question I ask every attendee here on the DevOps Chats, and that is, for our leaders out there listening, if they had to read one book which would really help them the most, what would be your suggestion?

    Carol Carpenter:        Gosh, there are so many great books. I would recommend the Phoenix Project. Have you read that, Alan?

    Alan Shimel:                Oh, as well, yeah. That’s what got me into dev-ops. I met Gene Kim about four or five years ago when the Phoenix Project was a manuscript,

    Carol Carpenter:        It’s just game changing, right? The Phoenix Project – it gives you an orientation and a framework around how to attack process challenges, and how to attack the full delivery, you know, the whole life cycle of soft ware or any process. Really, really insightful, and you know, obviously, it’s written in a parable format, so it makes it very enjoyable and easy to read.

    Alan Shimel:                Absolutely. It’s an easy read. Well, Carol Carpenter, CEO of Elastic Box, much continued success at Elastic Box, and again, the survey that we’ve done with Elastic Box and the real value of DevOps, is available if you go to Elastic Box, and you can find it at devopsy.kinsta.cloud as well.

    I’m interested in anyone’s feedback obviously on it. Carol, we hope to have you back again in the future, and thanks so much for being today’s guest. 

    Carol Carpenter:        Thank you, Alan.

    Real Value of DevOps

  • 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.

  • What is DevOps to you? New survey by ElasticBox and devopsy.kinsta.cloud

    What is DevOps to you? New survey by ElasticBox and devopsy.kinsta.cloud

    What is DevOps to you? Now that is a loaded question. For so long DevOps has defied definition. How can then we quantify it? How do you know if it is working? What do you spend on it? What exactly do you do when you do it? What tools do you use?

    While the folks over at Puppet Labs, Gene Kim and team have done a great job with their annual surveys showing DevOps adoption and its impact on high performing IT organizations, it is time to delve a little deeper into exactly what tools are we using, what works and what doesn’t work.  Heck, even what we consider working or not is still to be defined.

    So we are partnering with our friends at ElasticBox to conduct a survey to better understand what it is that you consider DevOps, what you are paying for it and do you consider it successful.

    You can take the survey in about 10 minutes or less.  You can take the survey right here: https://www.surveymonkey.com/s/devopsdot

    Oh wait there’s more. One in 50 respondents will win a $50 Amazon gift card (you need to supply contact info to win) and one grand prize winner will win a really nice 3DR IRIS+ Drone (pic below), again you must supply contact info to win)

    IRIS_goproWe will publish the results and analysis in July. So take 10 minutes and help us help the community with this vital information.

  • Bird’s Eye View of IT as a Service

    Bird’s Eye View of IT as a Service

    In working closely with large enterprises for several years, we consistently hear businesses talk of IT needs to achieve critical and strategic goals. Commonly these large enterprises span many verticals like technology, online media, finance, banking, and more.

    At the heart of their business goals, lie technology hurdles they need to overcome to scale as enterprises of the next decade.

    Visualizing IT as a service

    So we captured in this mind map high-level business goals that require a broad set of IT services ranging from infrastructure, applications, management, integration, service provider, and architecture.

    elasticbox-it-as-a-service-thumb

    If you look to the left, you see needs centered around applications. These detail all the services required to provision, deploy, and manage applications including application architecture models to design automated deployments and serve all the right infrastructure resources.

    On the right, you see needs that revolve around compliance, reporting, and integrating with various service providers to supply virtual infrastructure and a slew of related services to keep the infrastructure running smoothly and reliably.

    We find that this visual captures the entire IT-as-a-service industry as a whole and this exercise helps to understand where the customers’ needs are and where in that spectrum we assist them.

    See if you can pinpoint the areas where DevOps and IT Ops come into play.

    Enjoy the mind map and click to see a larger PDF view!

  • Bringing Collaboration, Orchestration and Lifecycle Management to Docker Containers

    Bringing Collaboration, Orchestration and Lifecycle Management to Docker Containers

    As you most likely know, Docker is a Linux container technology that stands to revolutionize or standardize the delivery mechanism of applications and services in the cloud.

    Docker, which just turned 1.0, has created an enormous amount of buzz, a vibrant community, and an extremely interesting ecosystem upon which developers and operations teams can draw to ultimately build better applications and better utilize cloud resources.

    We, at ElasticBox, wanted to see what we could do by combining these two great technologies. With developer and IT operations in mind, we’ve created the ability for you to consume Docker as a service with  collaboration, orchestration, and lifecycle management capabilities. You can now create Boxes and use Docker as a service, giving you and your team the ability to distribute Docker files as Boxes across your organization, collaborate on the continued development and maintenance of these assets, provide an orchestration tool for the deployment of application or infrastructure components, and finally, manage their lifecycle across different environments – development, test or production.

    Tutorial – Deploy the Ghost blogging platform in a Docker Container on any cloud using ElasticBox

    To demonstrate this integration, let’s launch an instance of Ghost, a simple but powerful publishing platform, in a Docker Container on the Cloud Provider of your choice. By the end, you will have built a Ghost / Docker Box in ElasticBox that can be deployed, versioned and shared. For step by step instructions, click through the Slideshare below.

    For more information on how to use Docker in ElasticBox, please visit our documentation.

     

  • ElasticBox Jenkins Plugin – Easy Continuous Integration Setup

    ElasticBox Jenkins Plugin – Easy Continuous Integration Setup

    Introduction to Jenkins and ElasticBox

    ElasticBox has recently released a Jenkins plugin which makes it possible to configure a continuous integration or continuous deployment scenario without writing any code or scripts! How have we done this you ask? Simple, it was magic. In all seriousness, magic is the end result if you integrate ElasticBox and Jenkins with the source control software of choice.

    For those who rely on Jenkins for daily work, performing integration builds, orchestrating complex, large scale scenarios for testing or managing continuous delivery of applications with many configurations across multiple environments, is not uncommon. These types of scenarios require a lot of time setting up slaves and performing manual steps to configure the provisioning of cloud providers. Keeping consistency and across the environments becomes exponentially complex when you factor multiple clouds or hybrid cloud environments into the picture.

    You can reduce the amount of manual configuration and scripting, while abstracting the provisioning of infrastructure, by using ElasticBox with the ElasticBox Jenkins Plugin. This means that you can use ElasticBox to solve complex continuous integration or deployment use cases in the quickest, most consistent and reliable way possible.

    How Does It Work:

    Here at ElasticBox we trigger tests, builds, and deployments on pull requests and merges, which is a very common use case. These actions start workflows that result in Jenkins triggering tests, builds and the deploying of instances. For more information on our internal continuous deployment scenario, take a look at this slideshare deck we presented earlier this year.

    The first thing to understand is that we manage Jenkins as an instance that we deploy into our private datacenter through ElasticBox. We have a single Box that installs Jenkins Server on the provider of your choice. This makes it convenient to scale when multiple builds are slowing things down or to simply redeploy if something breaks all together.

    The second piece of the puzzle are the required plugins, like the recently releasedElasticBox Jenkins Plugin, which, along with the Github Jenkins Plugin, makes it entirely possible to set up a continuous integration or deployment server without writing any code.

    Setting Up Jenkins and ElasticBox:

     

    First you have to set up ElasticBox as a cloud in the configuration page of Jenkins. You simply enter the ElasticBox url (http://elasticbox.com), a maximum number of instances, retention time, in minutes, and your ElasticBox username and password. Once all this information is entered correctly, you can go ahead and then test the connection.

     

    Screenshot 2014-07-01 17.57.13

     

    ElasticBox Jenkins Example:

    In this basic example, we’ll show you how we test changes to our website. When a branch is submitted as a pull request, we deploy a new staging instance of our Website Box. We validate the changes on an instance that is a replica of our production environment before merging the pull request into our master branch. When the code is merged, we then trigger a Jenkins job that reinstalls our production instances with the latest code changes (not shown in this demo). Now, our workflow for website changes is almost fully automated, minus the pull request and merge!

    1) The first step is to create a new Jenkins item where we select “Build a free-style software project”

     

    Screenshot 2014-07-02 11.34.50

    2) Once we’ve created a new item, we add the Github project URL and check the ‘this build is parameterized’ box. While this step isn’t required, it allows you to trigger a build manually and execute code from a specific branch.

    Screenshot 2014-07-02 11.46.36

     

    3) In the source code management section, we specify the source code management tool, the ‘Repository URL’, provide credentials in the form of Username / Password, and for the Branch Specifier, use ‘${sha1}’ which represents the commit url of the branch submitted in the pull request. The Jenkins Git plugin is extremely complex and we highly recommend reading the Wiki on the plugin.

    In the Build Triggers section, you’ll want to select “Github Pull Request Builder” Which is what will be triggering the Jenkins build and instance deployment in ElasticBox.

    Screenshot 2014-07-02 11.48.44

    4) The final step is configuring the Build steps. With the ElasticBox plugin, you’ll have access to all your workspaces, boxes and deployment profiles. For more information on each of these features, please check out the links to our documentation. Specify the Workspace, the Box and the Deployment profile you would like to use. In our case, we specify our Production Workspace, our Website Box and our Staging Deployment Profile.

    Screenshot 2014-07-02 13.31.32

     

    Conclusion:

    Once all these configurations are set, you can test changes on new staging instances just by submitting pull requests. Even though this is a basic example, by continuous integration standards, you can see how the ElasticBox Jenkins plugin can seriously reduce the amount of configurations required to setup a continuous integration server.

    With ElasticBox abstracting the infrastructure provisioning and allowing you to reuse existing application or infrastructure components, it’s much easier to scale the process in a repeatable and dependable way. We’ll be following up with blog posts that provide more technical examples on how to use Jenkins and ElasticBox for integrated builds, testing and continuous delivery models.

  • Deploying a MongoDB Cluster with ElasticBox

    Deploying a MongoDB Cluster with ElasticBox

    Our founders, back in the day,  were part of the .NET framework team at Microsoft. So it’s no surprise that their first version of ElasticBox was written on C#, .NET framework and SQL Server.

    Fast forward to 2012. As the ElasticBox vision crystallized, we wanted a robust, scalable architecture to match our vision. So we reevaluated all the existing technologies.

    Among other things, we decided to move from a relational database model to a document based approach. The main reason was because we wanted to store hierarchical data and be able to version it.

    Today, to accommodate our data needs, ElasticBox relies on MongoDB clusters, which we run on three separate providers–two public, one private. Thanks to ElasticBox, we can now deploy our MongoDB cluster in a matter of minutes.

    The Basics

    What is MongoDB? MongoDB is an open-source document store database.

    Why would you want to cluster MongoDB? To provide redundancy and high-availability for production deployments.

    How We Use MongoDB

    In our case, MongoDB is using a replica set model. A replica set is a group of MongoDB instances that host the same data set. One MongoDB, the primary, receives all write operations. All other instances, secondaries, apply operations from the primary so that they have the same data set.

    The primary accepts all write operations from clients. Replica sets can have only one primary. Because only one member can accept write operations, replica sets provide strict consistency.

    Screenshot 2014-06-18 16.47.20

    Deploying MongoDB through ElasticBox

    ElasticBox provides a default MongoDB box that’s available to the public. It deploys a standalone instance of the MongoDB server. Our MongoDB production box very closely resembles the default box, minus a few configuration settings required for our production scenario.

    While the default MongoDB box configuration is suited for development purposes, it needs to be configured further to use in production. To configure the MongoDB default box for production use, follow the steps below:

    Step 1. Create a new box called MongoDB Replica. Add a box variable for the MongoDB Server (this is to use the default box settings).Screenshot 2014-06-18 16.11.18

    Screenshot 2014-06-18 16.12.08

    Step 2. Add a text variable REPLICA_SET to hold the replica set name. This value must be shared between all the members of the cluster.

    Screenshot 2014-06-18 16.12.42

    Step 3. Expand the MongoDB Server box. Edit its file variable COMMON_YAML and paste the following:

    Screenshot 2014-06-18 15.35.45

    mongodb::replica_set: {{ REPLICA_SET }}

    mongodb::key_file: /etc/mongod.key

    Screenshot 2014-06-18 16.15.36

    This file will be used by hiera to pass arguments to puppet automatically without modifying the existing puppet default.pp file.

    Step 4. Add a binding named primary of type MongoDB Replica (the box you just created).

    Screenshot 2014-06-18 16.14.05

    Step 5. Add an install script. Get the script here.

    Screenshot 2014-06-18 16.16.10

    Screenshot 2014-06-18 22.34.28

    Step 6. Add a start script. Get the script here.

    Screenshot 2014-06-20 11.40.08Screenshot 2014-06-20 11.40.35

    When you deploy the box without a binding, it creates a cluster for you with an initial configuration. On the other hand, if you bind to an existing instance, it adds the instance to the existing cluster!

    There, you have it, a MongoDB cluster in a few easy steps!