Category: Features

  • Gene Kim shares his thoughts on upcoming Jenkins User Conference

    Gene Kim shares his thoughts on upcoming Jenkins User Conference

    DevOps is coming to Virginia June 18 and 19. The Jenkins User Conference is being held in Alexandria and one of the keynote speakers is none other than Gene Kim—one of the original leaders of the DevOps movement. I had a chance to speak with Kim about what he plans to present and about his thoughts on the current state and future direction of DevOps in general.

    Kim told me he’s looking forward to speaking in front of the Jenkins User Conference audience. One of the core elements of his presentation will be a closer look at the principles and patterns of successful DevOps organizations and the lessons we’ve learned so far as a DevOps community. He told me he’s not interested in “unicorns”—the big name companies like Netflix or Facebook that were early adopters and DevOps innovators. He is more interested in the “horses”—ordinary companies effectively employing DevOps to do extraordinary things.

    Over the last year or two I have written a number of articles around the theme of DevOps being undefinable. I’ve asserted that there’s no default DevOps solution and that if you asked 10 different organizations to define what DevOps means you’d get 15 different answers. Gene Kim does not agree.

    Kim told me that he takes the completely opposite position—that there are unmistakable characteristics of DevOps. An organization can choose to call something DevOps, but according to Kim if it’s lacking in these core elements it will not succeed.

    He said that there are certain core principles that comprise DevOps and enable organizations to develop and operate faster. The principles Kim listed were peer review, less management approval required, rigorous automated testing, the ability to create entire environments on demand, and one-click deployment. Many of the core elements are a reflection of the culture shift required to successfully implement DevOps.

    Kim didn’t just pull this stuff out of thin air, either. He and some partners recently shared the results of a comprehensive study of 9,200 organizations scattered across 110 countries. The research revealed that the high-performers—those who have successfully embraced these core principles—do better than the non-high-performers by two orders of magnitude or better.

    Put another way, those organizations that are employing DevOps effectively are poised to blow their rivals completely out of the water. DevOps isn’t just a different approach to infrastructure or development—it has a direct impact on the bottom line. One part of the study found that high-performers have 8,000 times faster lead times than their peers. How can an organization that isn’t using DevOps compete with a rival that can produce 8,000 times faster than they can?

    That brings me to the other aspect of the Jenkins User Conference that Kim is excited about: the diversity of the organizations represented there. Both in terms of the companies represented by the presenters and the companies represented by the attendees, it’s apparent that DevOps has reached a critical mass of mainstream adoption. Organizations from Agilant and AirBus to IBM, Perfecto Mobile and Pivotal have respected professionals sharing knowledge about DevOps.

    If you happen to be in the Alexandria area or plan to be in a couple weeks you should try to go to the Jenkins User Conference. If you’re company isn’t using DevOps you’re already behind the learning curve. If you don’t catch up soon a competitor will out-perform you by two orders of magnitude and you won’t have a company anymore.

  • Top 3 DevOps Practices for Operational Stability

    Top 3 DevOps Practices for Operational Stability

    Operational Stability is one of the main concerns in organizations. Especially some larger organization struggle to get a more stable IT landscape. Too often it’s political discussions that are preventing them from doing something about it. Organizations that have DevOps teams in place can just smile because they are enabled to be in control of their entire delivery chain from development to production. Read about what DevOps teams do in order to be real DevOps and why they’re smiling all day long.

    (more…)

  • RedHat Culture Keeping the DevOps Faith

    RedHat Culture Keeping the DevOps Faith

    Red Hat is readily recognized for its accomplishments with Linux and software design. The Red Hat DevOps culture itself started by design as a program built on training developers in operations skills and increasing operations’ faith in these developers. Red Hat’s IT Platform Operations Manager, Anderson Silva tells devopsy.kinsta.cloud how internal teams initiated the cultural change inside this Linux development icon.

    Get Back In Line!

    The Platform Operations team in IT manages and executes a lot of the deployments of IT-managed applications into these environments, says Silva. On the road to establishing Red Hat’s internal DevOps dynasty and prior to running the Platform Operations team, Silva captained a small band of operations folk in a department known as Production Control. There Silva and crew established controls to ensure that any new deployments would not and could not break the production environment.

    “Sometimes this meant we had to halt the whole of a deployment because a developer forgot to add one link to our release documentation, putting them back in line with everyone else who was requesting permission to deploy,” says Silva. Feeling that Production Control as such was more the bottleneck than a deployment solution, Silva saw this as a challenge to Red Hat that would be increasingly important and increasingly difficult to meet.
    In those days before DevOps was cool, a Red Hat development manager came to the rescue with a program to turn that bottleneck into a solution that could speed up the deployment process. According to Silva, this first initiative was the root of what became known at Red Hat as the Lieutenant program, which supports developers willing to gain the Red Hat Certified Engineer certification so they could enjoy production and pre-production access and manage each their own deployments as frequently as they liked. Red Hat eventually added a “corporals” component as an additional and similar program. These developers in “corporals” gained QA access and did not have to earn the RHCE certification to get it.

    Riveting Results

    “These two programs added significant value over the years. By building trust between developers and operations, we addressed many technical issues that we had historically viewed as ‘another person’s problem’,” says Silva, who also holds the RHCE and RHCA certifications and actively maintains a Fedora Package. Red Hat continues to foster a flexible DevOps culture and to nurture the flexibility that sprouts from added trust between engineers and developers.

    That flexibility is paying dividends. Where as it once took Red Hat a week to develop and deploy software for about 20 servers to its staging environment, today the Linux titan can complete such a release a few times a day, says Silva. “I wouldn’t be surprised if in the near future we are able to do it a few times an hour when necessary,” Silva says.

    And by keeping the faith between operations and development, Red Hat can limit the risk that might otherwise come with its migration to its hybrid cloud. This DevOps-relationship-based culture will also benefit Red Hat’s new image-based deployments, which count on tools that are common among members of this culture such as the Red Hat Enterprise Linux OpenStack Platform, OpenShift, Kubernetes (a data center tool), and Docker.

    “As an open source company, we use open source solutions where possible and we have written our own tools to help us automate deployments,” says Silva. As Red Hat’s Platform Operations team is about to retire some of these tools in favor of others, it is also reaching out to other internal IT departments to spread the use of image-based deployments, which also leverage Jenkins, AWS, Puppet, Ansible, and Git.

    The DevOps culture that a few managers seeded within departments has borne fruit in the form of a top-down leadership example that rewards and encourages developers who innovate. Red Hat draws temporary ad hoc teams including sys admins and developers together to address nagging development issues. The key to success, says Silva, is in working on these challenges together instead of finding someone to blame.

    Free Advice

    Silva advises that enterprise leaders who want to wade into fostering a DevOps culture focus on their people before whatever looks new and shiny among the many choices for tackling DevOps approaches. “Trust your people and let them do their jobs. When mistakes happen, don’t look to blame; look for a solution. Then take a look at what’s new and shiny,” Silva says.

  • DevOps Connect: SecDevOps @RSA the videos

    DevOps Connect: SecDevOps @RSA the videos

    Back in April we were proud to partner with RSA Conference, IT Revolution, Sonatype, TheNexus and RuggedSoftware.org to bring DevOps Connect: SecDevOps to the Moscone Center. It was a full day of great DevOps and Security presentations. For me personally it succeeded beyond my wildest dreams of highlighting the intersection of DevOps and Security.

    The line up of speakers and topics that day was extraordinary.  In no particular order:

    • Gene Kim/Josh Corman – Rugged DevOps: Going Even Faster With Software Supply Chains
    • Jez Humble – Continuous Delivery
    • David Mortman – DevOps Myths Versus Real World Realities
    • Julie Tsai – Windfall Wins: DevOps Empowers Agile Security and Compliance
    • Constantine Aaron Cois – DevOpsSecFail: DevOps Security Anti Patterns
    • Terri Potts – Leading a Horse to Water and Enticing Him to Drink
    • Nick Galbreath – BYOD: Bring Your Own Dependencies
    • Jessica Devita – No White Boards Allowed
    • Rich Mogull – Building Your SecDevOps Toolkit
    • Dan Cornell and Kris Curylo – Blending the Automated and the Manual
    • Damon Edwards and Alex Honor – Coaches and Toolsmiths
    • Dan Cundiff – Why DevOps != the Wild West and How Embracing it Can Improve Security
    • Chris Corriere – Automating Enterprise Security
    • Chris Walsh – I’m the New Security lead, and I’m Here to Help

    The good news is we had hired professional video crew to tape all of the presentations. Then through the efforts of Mark Miller and Derek Weeks of Sonatype the actual presentations were edited into the videos, creating a fantastic video recreation of the sessions.  Here is a short preview of sessions:

    In all there are over 10 hours of fantastic DevOps content here spread over the 14 presentations.  Through TheNexus and devopsy.kinsta.cloud we are making them available to you free. The only obligation is your fill out a registration form.

    Fill out the form here.

    Please note that the form submission will generate an email to verify your identity. You can access the entire video library via that email.  We ask that you please not share the URL of the videos and instead direct viewers to this page or TheNexus to download for themselves.

    Also, if you are attending InfoSecurity Europe this week, be sure to check out DevOps Connect: Rugged DevOps, Thursday, June 4 all day at the Olympia. Here is the lineup:

    Agenda

    8.30- 9.00             Meet and Greet

    9.00-9.10              Introductions: Alan Shimel and Wai Man Yau

    9.10-9.50              Keynote Presentation: Dr. StrangeOps: How I Came to Embrace Rugged DevOps & SW Supply Chains, Joshua Corman, CTO, Sonatype and Rugged  

    9.50-10.30           Maintaining Control While Letting Go, Gareth Rushgrove, Puppet Labs

    10.30-11.00         Security at Speed; Best Practices for a Secure DevOps Implementation, Florin Coada, IBM 

    11.00-11.30         The DevOps Toolkit, Helen Beal, Head of DevOps, Ranger4 Limited

     11.30-12.00         A Manifesto for High Velocity Compliance, Justin Arbuckle, Vice President, EMEA & Chief Enterprise Architect, Chef

     12.00-13.00         Opportunity to visit the Infosecurity Europe Exhibition

     13.00-13.30         Secrets Within Your Java-Based Software Supply Chain, Derek Weeks, VP, Sonatype & DevOps Advocate

     13.30-14.00         Automating Security Tests for Continuous Integration, Stephen de Vries, CTO, Continuum Security

    14.00-14.30         SecDevOps 2.0- Managing your Robot Army, Elizabeth Lawler, CEO and CoFounder, Co-Founder Conjur Inc

    14.30-15.00         Case study: DevOps Cost-Effectively Secured Quality and Time-to-Market for a Complex Hardware/Software Network Product, Marc Hornbeek, Senior Solutions Architect, Spirent Communications

    15.00-15.15         Afternoon break

    15.15-15.45         DevOps:  How the Industrial Revolution Got Us Here, Jonathan Fletcher, Enterprise Architect – Technology & Platform (DevOps) Lead

    15.45-16.15         Transforming to Devops in the Enterprise, Benjamin Wootten, Co-Founder, Contino

    16.15-16.45         SecDevOps: From Zero to $2.5B Revenue in 18 Months, Justin Lundy, CIO/CTO, Evident.io

    16.45-16.50         Thank you and close, Alan Shimel and Wai Man Yau

     

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

  • Bigdata – Understanding Hadoop and Its Ecosystem

    Bigdata – Understanding Hadoop and Its Ecosystem

    It is quite interesting to envision how we could adopt the Hadoop eco system within the realms of DevOps. I will try to cover it in upcoming series.  Hadoop managed by the Apache Foundation is a powerful open-source platform written in java that is capable of processing large amounts of heterogeneous data-sets at scale in a distributive fashion on cluster of computers using simple programming models. It is designed to scale up from single server to thousands of machines, each offering local computation and storage and has become an in-demand technical skill. Hadoop is an Apache top-level project being built and used by a global community of contributors and users.

    Hadoop Architecture:

    The Apache Hadoop framework includes following four modules:

    • Hadoop Common: Contains Java libraries and utilities needed by other Hadoop modules. These libraries give filesystem and OS level abstraction and comprise of the essential Java files and scripts that are required to start Hadoop.
    • Hadoop Distributed File System (HDFS): A distributed file-system that provides high-throughput access to application data on the community machines thus providing very high aggregate bandwidth across the cluster.
    • Hadoop YARN: A resource-management framework responsible for job scheduling and cluster resource management.
    • Hadoop MapReduce: This is a YARN- based programming model for parallel processing of large data sets.

    Below diagram portray four components that are available in Hadoop framework.

    Hadoop

    All the modules in Hadoop are designed with a fundamental assumption i.e., hardware failure, so should be automatically controlled in software by the framework. Beyond HDFS, YARN and MapReduce, the entire Apache Hadoop “platform” is now commonly considered to consist of a number of related projects as well: Apache Pig, Apache Hive, Apache HBase, and others.

    Hadoop Ecosystem:

    Hadoop has gained its popularity due to its ability of storing, analyzing and accessing large amount of data, quickly and cost effectively through clusters of commodity hardware. It wont be wrong if we say that Apache Hadoop is actually a collection of several components and not just a single product.

    With Hadoop Ecosystem there are several commercial along with an open source products which are broadly used to make Hadoop laymen accessible and more usable.

    The following sections provide additional information on the individual components:

    MapReduce

    Hadoop MapReduce is a software framework for easily writing applications which process big amounts of data in-parallel on large clusters of commodity hardware in a reliable, fault-tolerant manner. In terms of programming, there are two functions which are most common in MapReduce.

    • The Map Task: Master computer or node takes input and convert it into divide it into smaller parts and distribute it on other worker nodes. All worker nodes solve their own small problem and give answer to the master node.
    • The Reduce Task: Master node combines all answers coming from worker node and forms it in some form of output which is answer of our big distributed problem.

    Generally both the input and the output are reserved in a file-system. The framework is responsible for scheduling tasks, monitoring them and even re-executes the failed tasks.

    Hadoop Distributed File System (HDFS)

    HDFS is a distributed file-system that provides high throughput access to data. When data is pushed to HDFS, it automatically splits up into multiple blocks and stores/replicates the data thus ensuring high availability and fault tolerance.

    Note: A file consists of many blocks (large blocks of 64MB and above).

    Here are the main components of HDFS:

    • NameNode: It acts as the master of the system. It maintains the name system i.e., directories and files and manages the blocks which are present on the DataNodes.
    • DataNodes: They are the slaves which are deployed on each machine and provide the actual stor­age. They are responsible for serving read and write requests for the clients.
    • Secondary NameNode: It is responsible for performing periodic checkpoints. In the event of NameNode failure, you can restart the NameNode using the checkpoint.

    Hive

    Hive is part of the Hadoop ecosystem and provides an SQL like interface to Hadoop. It is a data warehouse system for Hadoop that facilitates easy data summarization, ad-hoc queries, and the analysis of large datasets stored in Hadoop compatible file systems.

    It provides a mechanism to project structure onto this data and query the data using a SQL-like language called HiveQL. Hive also allows traditional map/reduce programmers to plug in their custom map­pers and reducers when it is inconvenient or inefficient to express this logic in HiveQL.

    The main building blocks of Hive are –

    1. Metastore – To store metadata about columns, partition and system catalogue.
    2. Driver – To manage the lifecycle of a HiveQL statement
    3. Query Compiler – To compiles HiveQL into a directed acyclic graph.
    4. Execution Engine – To execute the tasks in proper order which are produced by the compiler.
    5. HiveServer – To provide a Thrift interface and a JDBC / ODBC server.

    HBase (Hadoop DataBase)

    HBase is a distributed, column oriented database and uses HDFS for the underlying storage. As said earlier, HDFS works on write once and read many times pattern, but this isn’t a case always. We may require real time read/write random access for huge dataset; this is where HBase comes into the picture. HBase is built on top of HDFS and distributed on column-oriented database.

    Here are the main components of HBase:

    • HBase Master: It is responsible for negotiating load balancing across all RegionServers and maintains the state of the cluster. It is not part of the actual data storage or retrieval path.
    • RegionServer: It is deployed on each machine and hosts data and processes I/O requests.

    Zookeeper

    ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization and providing group services which are very useful for a variety of distributed systems. HBase is not operational without ZooKeeper.

    Mahout

    Mahout is a scalable machine learning library that implements various different approaches machine learning. At present Mahout contains four main groups of algorithms:

    • Recommendations, also known as collective filtering
    • Classifications, also known as categorization
    • Clustering
    • Frequent itemset mining, also known as parallel frequent pattern mining

    Algorithms in the Mahout library belong to the subset that can be executed in a distributed fashion and have been written to be executable in MapReduce. Mahout is scalable along three dimensions: It scales to reasonably large data sets by leveraging algorithm properties or implementing versions based on Apache Hadoop.

    Sqoop (SQL-to-Hadoop)

    Sqoop is a tool designed for efficiently transferring structured data from SQL Server and SQL Azure to HDFS and then uses it in MapReduce and Hive jobs. One can even use Sqoop to move data from HDFS to SQL Server.

    Apache Spark:

    Apache Spark is a general compute engine that offers fast data analysis on a large scale. Spark is built on HDFS but bypasses MapReduce and instead uses its own data processing framework. Common uses cases for Apache Spark include real-time queries, event stream processing, iterative algorithms, complex operations and machine learning.

    Pig

    Pig is a platform for analyzing and querying huge data sets that consist of a high-level language for expressing data analysis programs, coupled with infrastructure for evaluating these programs. Pig’s built-in operations can make sense of semi-structured data, such as log files, and the language is extensible using Java to add support for custom data types and transformations.

    Pig has three main key properties:

    • Extensibility
    • Optimization opportunities
    • Ease of programming

    The salient property of Pig programs is that their structure is amenable to substantial parallelization, which in turns enables them to handle very large data sets. At the present time, Pig’s infrastructure layer consists of a compiler that produces sequences of MapReduce programs.

    Oozie

    Apache Oozie is a workflow/coordination system to manage Hadoop jobs.

    Flume

    Flume is a framework for harvesting, aggregating and moving huge amounts of log data or text files in and out of Hadoop. Agents are populated throughout ones IT infrastructure inside web servers, application servers and mobile devices. Flume itself has a query processing engine, so it’s easy to transform each new batch of data before it is shuttled to the intended sink.

    Ambari:

    Ambari was created to help manage Hadoop. It offers support for many of the tools in the Hadoop ecosystem including Hive, HBase, Pig, Sqoop and Zookeeper. The tool features a management dashboard that keeps track of cluster health and can help diagnose performance issues.

    Conclusion

    Hadoop is powerful because it is extensible and it is easy to integrate with any component. Its popularity is due in part to its ability to store, analyze and access large amounts of data, quickly and cost effectively across clusters of commodity hardware. Apache Hadoop is not actually a single product but instead a collection of several components. When all these components are merged, it makes the Hadoop very user friendly.

  • Atlantic.Net Credits DevOps Culture to Mental Agility

    Atlantic.Net Credits DevOps Culture to Mental Agility

    Atlantic.Net (www.atlantic.net) is a Solid State Drive-based cloud hosting provider with locations in New York City, San Francisco, Dallas, Toronto, Orlando, and (coming soon) London and Singapore, says Marty Puranik, Founder & CEO, Atlantic.Net. The Atlantic.Net cloud system is an intuitive IaaS server environment for customers who are developers. The company backs its 24/7/365 operation with a deep, full stack DevOps integration throughout the organization.

    That means that everyone has enough understanding of everyone else’s area within the company and of how everything is orchestrated so that when there is a change for the organization to make, everyone appreciates everything everyone else needs to touch to make the change successful. “That’s versus operating in a silo as only a database administrator or only a web developer,” says Puranik.

    The Atlantic.Net software stack that makes change possible includes Linux, Nginx (http://nginx.org/), PHP (http://php.net/) /Python (https://www.python.org/), RESTful APIs for internal apps linkages, jQuery (https://jquery.com/), Ajax (http://www.w3schools.com/ajax/), MongoDB (/www.mongodb.org), node.js (https://nodejs.org), and KVM Virtualization. “We use serial protocols to communicate over Infiniband (a fast type of networking) so I would add SRP or iSER serial communications protocols, as well,” explains Puranik. (Infiniband is typically applied to high-performance computing applications.) Atlantic.Net applies a particular mindset as it uses these tools to serve its software, its customers, and its DevOps culture.

    Mental Agility Key to DevOps Culture

    Atlantic.Net teams feel that maintaining a mental agility across human resources and encompassing all stakeholders—customers, departments, and vendors, who often run DevOps teams, too—is a principal element of a thriving DevOps culture, according to Puranik. “Mental agility here means the ability to reformulate your best case scenario using new tools or upgrades to existing tools. Mental agility also means not designing systems that are so married to a legacy piece of technology that it is impossible to move them off that technology,” explains Puranik.

    Atlantic.Net strives to design software such that they can easily add, change, or remove old and new technologies from the stack without making major revisions to the codebase. To do this, the Atlantic.Net team puts considerable time into mulling over design considerations prior to implementation to ensure flexibility in the relationships between technologies and the development stack. The team takes the additional time in order to abstract different models of how a new feature could work so they can make the best selection for everyone. That’s a better choice than tightly integrating the new technology simply because it’s easier for them to think through and makes development go faster. “In this sense, mental agility means keeping your options open so you don’t end up with your back against the wall and your best path cut off,” says Puranik.

    The benefits of this type of mental agility are two-fold: the ability to continually evolve the codebase without any drag or friction from permanent ties to dated development moves; and, the ability to add functionality for customers with minimal code changes and without breaking the code.

    Stretching Out Strategy to Satisfy Stakeholders

    The nimble minds at Atlantic.Net take stakeholders into account because of the repercussions on customers, employees, and vendors of misguided changes to the software. “If, for example, we alter how a customer must access a particular feature, this creates a learning process for the customer,” says Puranik. If the change doesn’t carry enough value to make it worth the learning process, then the development team should not have put the customer or themselves through the whole mess.

    In the same way, adding a new expression of a software component such as an API from a third-party vendor brings the reliability of the vendor into question. “Can the vendor handle the number of queries we are going to make? If not, it’s bad for the vendor, for us, and ultimately for our customers,” says Puranik.

    Atlantic.Net must look at the entire development process from everyone’s angle, putting on their shoes and considering the outcomes of development choices. “Sometimes different people inside Atlantic.Net must be the champion on behalf of different stakeholders internally and externally to make the whole team think differently or at least think through what the outcome of specific actions might be,” says Puranik. That way continuous deployment is fast, and harmless—a win-win!

  • Moving from legacy to DevOps is a journey that takes time…and the right tools

    Moving from legacy to DevOps is a journey that takes time…and the right tools

    If you wanted to start a new company tomorrow it would be easy to look at the tech landscape and the prevalent trends and decide to just build everything around a DevOps culture from the beginning. Most of the companies in the world already exist, though, and they already have processes, tools in place. Making the move from legacy to DevOps isn’t just a moment-in-time decision—it’s an arduous journey over time.

    That’s where CloudBolt comes in. I had a chance last week to speak with CloudBolt CEO Jon Mittelhauser and CloudBolt CTO Bernard Sanders about the company, its vision, and the latest version of the CloudBolt platform. Mittelhauser explained that what customers appreciate about CloudBolt is the ability to transition from the past to the future on their own schedule.

    One of the problems with change is that it takes time. While the new process or tool you’re moving to might be better in every way, getting there can be a challenge. In the meantime you’re forced to manage and maintain disparate systems or platforms—both the old and the new. CloudBolt wants to help organizations reduce the chaos by providing a single platform that enables customers to administer all of the above.

    Large enterprises in particular don’t just adopt a new technology en masse. One site or department might start to use DevOps tools and processes out of necessity. Another department might also embrace DevOps—but choose different platforms and tools. Mittenhauser explained that even if the entire organization is on the same page about which DevOps tools and processes to use the transition occurs slowly over time—often by attrition as licenses expire or platforms reach the end of their support lifespan. Those customers still need a way to view and manage their entire ecosystem throughout the slow evolution.

    CloudBolt also shared that one of its newest customers—the London Borough of Camden—has adopted CloudBolt to get better insight and control of its vast virtual environment. “At a time of austerity in government, running a low-cost, flexible hybrid cloud service for our customers is essential. CloudBolt provides a service that enables our customers to get the compute power they need, on demand, increasing their productivity and reducing our administrative overheads,” said John Jackson, Assistant Director (ICT), London Borough of Camden.

    Sanders claims that CloudBolt v5—released Wednesday, May 27—makes it easier for IT admins to manage activities, applications, and services across a multi-cloud, multi-platform environment. He described a variety of new features in v5. According to the press release the list of new features includes:

    • powerful new service catalog functionality to facilitate complex, multi-tier app deployments
    • provisioning of service catalog blueprints available through both the CloudBolt web interface and a powerful REST API
    • deeper out-of-the box integration with technologies such as VMware, OpenStack, AWS, Azure, Infoblox, Puppet and Chef
    • ability to define arbitrary server actions so DevOps experts can provide simple buttons for users to perform complex operations on servers
    • ability to snapshot VMs from the CloudBolt user interface
    • increased control for administrators, including the ability to set rate-based limits and set limits on environments in addition to groups and handlers
    • significant UI improvements, including adding social aspects to the interface
    • even deeper extensibility – additional trigger points for hooks/actions
    • revamped docs, now made public: http://docs.cloudbolt.io
    • new trigger points for power on/off, rebooting servers and post-order completion process have been introduced and currency units are no longer limited to USD

    In many ways it would be easier to just switch gears and embrace the DevOps culture throughout an organization, but with large enterprises—and even some medium or smaller organizations—that is simply unrealistic. For organizations that are maintaining multiple technologies and environments during that transition a tool like CloudBolt can help IT monitor and manage everything efficiently.

    Existing CloudBolt customer can download the latest version from the support portal.

  • DevOps Connect: Rugged DevOps @Infosecurity Europe

    DevOps Connect: Rugged DevOps @Infosecurity Europe

    We have assembled another top flight list of speakers for our DevOps Connect event @Infosecurity Europe.  While pre-registration is sold out, if you are one of the 15,000+ attendees of Infosecurity Europe, you can still come to DevOps Connect on a first come, first serve basis.  Details and schedule are below:

    When: Thursday 4th June, Olympia London
    Time: 9.00 – 17.00

    Agenda for DevOps Connect:Rugged DevOps

    • 8:30am to 9:00am
      Meet and Greet
    • 9:00am to 9:10am
      Introductions – Alan Shimel and Wai Man Yau

    • 9:10am to 9:50am
      Joshua Corman, CTO, Sonatype and Rugged (Keynote)
      Dr. StrangeOps: How I Came to Embrace Rugged DevOps & SW Supply Chains

    • 9:50am to 10:30am
      Gareth Rushgrove, Puppet Labs
      Maintaining Control While Letting Go

    • 10:30am to 11:00am
      Florin Coada, Technical Specialist Graduate in Application Security at IBM
      Security at Speed; Best Practices for a Secure DevOps Implementation

    • 11:00am to 11:30am
      Helen Beal, Head of DevOps at Ranger4 Limited
      The DevOps Toolkit

    • 11:30am to 12:00pm
      Justin Arbuckle, Vice President, EMEA & Chief Enterprise Architect at Chef (formerly Opscode)
      A Manifesto for high velocity compliance

    • 12:00pm to 1:00pm
      Lunch Break

    • 1:00pm to 1:30pm
      Wai Man Yau, Sonatype EMEA
      Real World Customer Stories from the Software Supply Chain

    • 1:30pm to 2:00pm
      Stephen de Vries, CTO Continuum Security
      Automating Security Tests for Continuous Integration

    • 2:00pm to 2:30pm
      Elizabeth Lawler, CEO and CoFounder , Co-Founder Conjur Inc
      SecDevOps 2.0- Managing your Robot Army

    • 2:30pm to 3:00pm
      Marc Hornbeek, Senior Solutions Architect at Spirent Communications
      Case study – DevOps Cost-Effectively Secured Quality and Time-to-Market for a Complex Hardware/Software Network Product

    • 3:00pm to 3:30pm
      Jonathan Fletcher, Enterprise Architect – Technology & Platform (DevOps) Lead
      DevOps:  How the Industrial Revolution Got Us Here

    • 3:30pm to 4:00pm
      Benjamin Wootten, Co-Founder at Contino
      Transforming to Devops in the Enterprise

    • 4:00pm to 4:10pm
      Thank you and closing – Alan Shimel and Wai Man Yau

    If you are in London during these dates you can still register for Infosecurity Europe for free and attend DevOps Connect. Hope to see you there.

  • The DevOps-Price of Segregation of Duties.

    The DevOps-Price of Segregation of Duties.

    Segregation of duties will change because it must change. It has a tremendous impact on our motivation, time to market and IT Security. It influences many parts of an organization. Most organizations have started with DevOps, Continuous Delivery and Continuous Deployment and it is only natural to think about segregation of duties at one point and how we deal with it today. Today, it costs us a fortune that we’re not willing to pay in the near future. And why should we?

    (more…)