devopsy.kinsta.cloud

Category: Features

Case Study: Stytch Before, After DevOps Culture, Tools

Cloud analytics provider Stytch leverages its cloud-based analytics for customers who want to centralize, fuse and model their data. “Our mission is to make it easier and faster for business users to get insights and make decisions,” said Taylor Frost, cloud operations engineer at Stytch.

Before the company implemented a DevOps approach, its primary software platform and some services were large monoliths maintained by disconnected teams. Stytch tested new features in isolated Jenkins jobs and performed quality testing and product releases manually in siloed realms that were out of sight and out of mind, Frost said.

Stytch’s Dev, Ops and QA were walled from each other, isolating the knowledge base of activities in any one group from members of the other two groups. Stytch teams did not share this information, and sister teams could not benefit from the insights this knowledge held.

What’s more, developers did not have transparency into the products and tools that manipulated the cloud-based infrastructure or the build pipelines. “This fostered an attitude of ‘it’s an (Ops/Dev/QA) problem’ and discouraged a sense of ownership of or responsibility for success, which led to an increasingly lengthy feedback cycle and slower, less frequent builds,” Frost noted.

Stytch lacked the orchestration and the down-in-the-weeds level of control it needed to enable real-time changes to labyrinthine back-end technologies without repercussions that could cause the customer base to suffer, and to speed and simplify deployment, she said. Standards such as Terraform or CloudFormation did not provide the fine-grained control of deployment that Stytch needed.

The company’s Ops was in charge of Python software libraries, but other groups including Dev and QA needed access. Stytch also has a performance team that the company was eager to include in Python library development.

Stytch After DevOps

Stytch is using DevOps to unite teams and divide the various software monoliths into microservices for continuous integration (CI) and continuous delivery. The company has already fed its core software platform through the new build pipeline a number of times, and continues to create even more automated and efficient deployment processes.

As it works to create homegrown Python orchestration libraries, Stytch is establishing a stronger grip on deployment. All teams connected to the pipeline including Dev, QA and Performance are actively expanding these libraries.

Stytch increasingly intermarries its Dev, QA, Ops and Performance teams and enables and rewards collaboration across the stretch of the DevOps pipeline. “Our goal is transparent, scripted change integration, from check-in to testing and deployment. We empower our developers to take responsibility for their work, from check-in to production deployment,” Frost said.

Stytch uses frequent meetings of a continuous delivery committee with members from all four groups to update the status of the pipeline. The company is swapping out Jenkins for Travis CI for builds and tests, making Dev more hands-on and able to gauge its work from start to finish.

“Developers are iterating on their pipelines in the same way that they iterate on their projects,” Frost said. Stytch is able to find and fix problematic code earlier in the pipeline while accelerating development cycles. Customers are pleased with the faster rate of innovation on the software platform they use.

New Infrastructure, Training = More Results

Stytch has made cross-pollination of expertise common for pipeline teams. “We have an annual training allowance and our engineer-led ‘Ministry of Propaganda” holds regular afternoon sessions to introduce new technology and practices,” Frost said.

As CI and continuous delivery processes grow, absorb and automate manual steps, related activities across the pipeline become more translucent for everyone. Both the Travis CI platform and the use only of scripted product releases and scripted tests for performance are increasing that transparency.

The metamorphosis that has spread throughout the teams with direct access to the DevOps pipeline now extends to the rest of the company, as needed, such as with marketing. Frost provided an example:

“Our marketing team was struggling to make good progress with regular releases of our WordPress-based website. Our engineers were fielding regular requests for basic tasks—starting and stopping servers, updating configuration files and retrieving logs,” she said. “We brought our engineers and marketing together on this. The result was a simple command-line tool that enabled our nontechnical marketing staff to perform complex actions on their own, including promoting their changes to the production environment.”

August 15, 2016
DevOps Q&A: SUMO Heavy’s Brodie on the Hybrid Cloud

Not every expert says DevOps will enable the hybrid cloud. One says it never will. Find out why in this Q&A with Bob Brodie, partner and CTO of SUMO Heavy, a digital commerce design and development firm.

David Geer: How will DevOps enable the hybrid cloud?

Brodie: I do not feel that DevOps enables the hybrid cloud. Hybrid clouds are very complex, and DevOps would need to be supported by a team of network and system engineers. The beauty of being on the cloud is that it’s API-driven. You can provision servers and configure and deploy with tools that are easy to set up.

Bringing dedicated servers into that environment which do not have tooling to match the cloud counterpart means that it can’t be solely maintained by a DevOps team, but rather needs much more support. We have worked in hybrid cloud environments, and have experienced firsthand the amount of effort and resources required to create and maintain a hybrid cloud environment.

Geer: What makes hybrid clouds more complex than being either fully in the cloud or fully dedicated?

Brodie: When mixing dedicated servers with cloud servers on the same network, you will likely need parallel VPNs set up so you are not sending your data unencrypted over the internet and so that if there is a networking issue there is a fallback. Setting up full-duplex, parallel VPNs can require both expensive hardware and specialized resources to configure and maintain that hardware.

Geer: Why have tools such as some of the ones AWS is building (OpsWorks On-Premises) not hit the inflection point where these are making it easier to enable the hybrid cloud? What other tools are examples of this?

Brodie: OpsWorks On-Premises is just one tool that AWS has. They also have VPNs to connect your dedicated hardware to your virtual private cloud. These tools aren’t necessarily to make it easier to run a hybrid cloud, but they allow you to utilize existing AWS provisioning and deployment tools to set up and deploy to your existing infrastructure.

Geer: Why do you think these tools never will make it easier to enable the hybrid cloud?

Brodie: Hybrid cloud infrastructure is inherently more complex than being fully dedicated or fully cloud-based. They are two different types of ecosystems, and are managed differently. They require different skill sets and levels of experience within those ecosystems.

Geer: Please expand on your following statement: “The problem is that the methodologies behind the two schools of thought (Separate sysops and dev versus DevOps) are vastly different in thought and practice, and to really bring dedicated hardware into a cloud-based architecture is very cumbersome, especially if the dedicated environment is not utilizing complex virtualization.” What does the difference in schools of thought have to do with it? What does bringing dedicated hardware in have to do with it?

Brodie: My point here is that “DevOps” is often misused. It isn’t a tool, it is a mindset. It’s a combination of development and sysops. A “hybrid cloud” is a mix of dedicated hardware and cloud infrastructure. My main point here is that DevOps practices do not make managing enterprise developments easier across hybrid cloud environments. Hybrid cloud environments are inherently more complex than the alternatives (dedicated hardware or fully cloud-based).

The reason for this is that development is becoming more and more intertwined with sysops. For example, five years ago you could download MAMP onto your Mac and be fully set up with a PHP & MySQL development environment. Modern PHP development requires a developer to understand specific versions of PHP and MySQL, how to manage them, how various applications communicate with each other and, often times, many other applications (Redis, MongoDB, Queueing systems, etc.). These can be complex to maintain, and even if they are distributed to developers from the ops team, it will often be in the form of Vagrant boxes or Docker files, which the developer will be required to understand.

This is the nature of the “DevOps” school of thought, versus the traditional “SysOps separate from development” school of thought. The target environment needs to be considered when developing an application. For example, if the application will reside on AWS then the developer will need to have a solid understanding of the tools available on AWS (RDS, EC2, ElastiCache, etc.). The maintenance of these becomes part of the developer’s job, which was not present in previous times. Adding the extra complexity of a hybrid cloud means that the developer needs to understand the underlying network architecture of that system.

Geer: In what way is the hybrid cloud a settling point, mostly built on marketing?

Brodie: Hybrid cloud environments are not ideal. They are costly to maintain and provide more points of failure because of the networking between them. What it can do is provide a halfway point for CIOs that are reluctant to move to the cloud, so they can see some of the benefits on the cloud side and hopefully move their organization to the cloud.

Geer: What are organizations afraid to let go of?

Brodie: Many organizations are scared to move to the cloud. They may have a CIO/CTO that is afraid of “losing control.” I have seen many environments such as this.

August 10, 2016
Citizen Developers Can Benefit an Organization

In many organizations, IT resources are pushed to the breaking point while users increasingly demand new technologies, features and capabilities. Users who know a thing or two—often just enough to be dangerous—sometimes “expedite” matters by finding their own shadow IT solutions. Organizations can harness those efforts, though, as citizen developers by finding a way for IT and rogue users to work cooperatively toward a common goal.

Shadow IT can be a serious issue. Consequences arise when users store sensitive company data in the cloud using unsanctioned consumer-oriented services such as Dropbox or track customers or sales in a Google Sheets document. The company loses control and oversight of its own information because it no longer knows where it is, and IT can’t adequately protect data or processes it isn’t even aware of. Users who implement maverick solutions put the company and its data at risk.

On the flip side, these users understand best what is needed to get the job done. They’re the ones working in the trenches and whose employment depends on getting their job done effectively. IT might select or develop tools and mandate that users adopt them, but if they don’t deliver all of the capabilities users need—or worse, get in the way of efficient productivity—users often will take things into their own hands.

What if IT and employees work together? That is the promise of the citizen developers movement. It’s a recognition that IT has neither the resources nor the vision to deliver everything users need, while providing rogue users with a sanctioned framework for creating solutions that IT can approve and manage.

Michael Beckley, CTO of Appian, explained that “shadow IT” is a pejorative term used to describe business teams bypassing IT and enterprise architecture governance to purchase systems that may create disconnected silos. Citizen developers can leverage shadow IT or sanctioned IT. Most successful IT organizations embrace low-code platforms and other technologies that enable citizen developers to operate securely and transparently within IT’s domain.

“The best-designed products have always been built with the needs of the user from the outset,” Beckley said. “Who better than citizen developers to design software that enables organizations to transform customer experiences, launch compelling new products and manage risk efficiently? Citizen developers are motivated by the opportunity to create a new reality, not merely accepting the workplace as they found it.”

Organizations typically enable citizen developers by providing a cloud-based, low-code platform that enables IT to create managed integrations to core systems, and maintain governance and security without significantly limiting the creativity of users.

“Citizen developers are most successful when supported by IT,” Beckley said. “One critical area where IT can help is in promoting reuse and modularity in the applications and business processes that citizen developers build.”

Having worked in the trenches as an IT admin, I have firsthand experience dealing with maverick users who try to circumvent policies and go around IT. At the time, I saw that as an attack on my authority in my role as an IT admin. A lot has changed since then, though—both with the technologies and services available, and my own attitude. I have come to recognize that users know best what they want and need, and there should not be an adversarial relationship between IT and users.

By embracing citizen developers, organizations can harness that ingenuity and innovation to help make the whole company more productive.

August 4, 2016
The Big Shift: The State of Continuous Delivery

I wanted to call out a new report that we have just released here at devopsy.kinsta.cloud. The State of Continuous Delivery: The Big Shift by George Hulme, contributing editor here at devopsy.kinsta.cloud. In this report George takes a look at the current state of Continuous Delivery and how it is helping to transform software development and deployment.

From the report:

Increasingly, it is the ability to continuously deliver reliable software that meets both immediate market demand and internal business needs. Rather than software being delivered in substantially-sized quarterly or even annual updates, it is more often delivered in never-ending, bite-sized feature updates. This is happening with all software now, from apps on our phones to large enterprise applications.

Of course that is the just the beginning. George interviews many leaders of the CD market and gives you his own keen analysis based on his many, many (did I say many) years covering the world of technology. You can read the rest of the report by downloading it for free here.

devopsy.kinsta.cloud Reports

This is the first in a new series of reports that we have been working on here at devopsy.kinsta.cloud. Written by our award winning editors and writers, they are snapshots on the current state of key areas of the DevOps and Container markets. The reports are researched and written by the authors independent of any sponsorships. After the report is complete, we do ask if any organization will like to sponsor but it has no effect on the authors opinions. For instance in this report, CloudBees, the Enterprise Jenkins company is the sponsor.

So stay tuned for more reports coming soon! If you are interested in sponsoring a report or would like to suggest a topic for another report please contact me at editor@devops.com. In the meantime enjoy this look at the current state of Continuous Delivery.

August 2, 2016
Health Care’s Shift to the Cloud via the Hybrid Cloud, Part 2

In part one of this series, we looked at how the healthcare industry has changed, requiring integrations and interoperability that were not previously needed.

Having established that the cloud is the way to go and that the hybrid cloud is the stepping stone hospital CIOs are comfortable with, we must ask how DevOps can help.

DevOps in Health Care

The legacy HL7 connection technology healthcare facilities use is a great example of how DevOps brings interoperability to health care and the hybrid cloud. “We have a cloud-hosted HL7 interface that can connect to any number of different hospitals and to our system as well. That’s something that would be very difficult to do without a cloud-based HL7 interface,” said Mayank Thanawala, CTO of HealthLoop, a provider of a cloud-based platform to automate follow-up medical care.

Another challenge hybrid cloud can address concerns the registries that track patient episodes and the bundled payment initiatives that health insurance companies use to pay the hospital systems, Thanawala noted. “The challenge is that hospitals have to get the patient data into the registries in order to receive payment.”

A hybrid cloud makes it easier to submit data to the registries because it provides an opportunity to connect to the registries using a system that already connects with the EMR system also and contains other data useful for registries and payments.

Thanawala illustrated registry solutions in the hybrid cloud. The Comprehensive Care for Joint Replacement Program is a large registry hosted by Medicare CMS. Hospitals need data such as diagnosis histories from medical records and patient-reported survey information to submit to this registry. “So, in an example of a hybrid cloud, HealthLoop is a cloud system that uses a web interface to ask the patients the questions and collect the data. Then we use this hybrid cloud-based HL7 interface to query the on-premises EHR (electronic health records) system for all the rest of the data, fill in the blanks, create this file for this registry, and basically solve the hospital’s problem,” he said.

How DevOps Speeds the to the Hybrid Cloud

DevOps and the move to containers have helped accelerate health care’s move to the hybrid cloud. “When you deploy a Ruby on Rails API in, say, a Docker container, because of how the container is configured it is going to take care of logging for all of the applications and transactions and putting those in a store that will keep the transactions for the seven-year period that HIPAA requires,” Thanawala said. This automation saves the hospital CIO the step of having the logging set up.

In the same way, if encryption of data both in flight and at rest is set up automatically in the container default configurations, that’s another matter the hospital CIO doesn’t have to worry about, he said.

If applications are set up as microservices in containers so that they already perform all these functions when containers are created or scaled up, the hospital and HIPAA requirements surrounding these activities automatically are met. “This lets startups like HealthLoop focus on building app functionality so we don’t have to worry about these other more involved matters,” Thanawala noted.

Even with health care’s complex move to the hybrid cloud, the modularity, completeness and singularity of applications in container technology as microservices make it possible to configure the containers, use them as building blocks and to build out efficient, scalable solutions in the cloud, he said. “It allows companies such as Catalyze, a medical systems integration and compliance organization, which we use to offer its products in a PaaS (platform-as-a-service) model using compliant containers so that we can simply deploy the containers and not have to worry about building compliance.”

Saving Time, Effort, Worry

HealthLoop’s story is a great example of how the automation and modularity of DevOps components such as containers and microservices can make or break new business opportunities, such as taking health care to the cloud and solving interoperation challenges.

July 29, 2016
Black Duck, HPE Partner to Protect Open Source
Open-source software has a number of significant benefits. For starters, it’s both free, which is hard to beat, and open, which means developers can customize or modify it to fit their needs. One issue with open-source software, however, is security. Black Duck has established itself as a leading tool for managing security of open-source tools—and now that protection is extended to HPE Security Fortify.

“Use of open source has increased dramatically in the last five years because it cuts development costs and accelerates time to market. Open source is ubiquitous worldwide and can comprise 50 percent or more of a large organization’s code base,” noted Black Duck CEO Lou Shipley in a press release announcing the HPE integration. “By integrating Black Duck Hub with HPE Security Fortify, customers will have visibility into and control of the open source they are using and also be able to identify known vulnerabilities. This allows them to better understand and reduce their security risks.”

Black Duck lists a variety of key features and benefits of the HPE Security Fortify integration:
- Deep Discovery of Open Source: Rapid scanning and identification of open-source libraries, versions, license and community activity powered by the Black Duck KnowledgeBase, a comprehensive open-source database containing information on more than 1.5 million open-source projects and more than 76,000 known open-source vulnerabilities.
- Comprehensive Identification of Open Source Risks: Create an inventory of all open source in use and a map to known security vulnerabilities, identifying and prioritizing the severity of the vulnerability and exploring remediation steps.
- Integrated Remediation Orchestration and Policy Enforcement: Open-source vulnerability remediation prioritization, mitigation guidance and automated policy management, allowing organizations to have visibility into their remediation efforts and manage their external and internal compliance mandates.
- Continuous Monitoring for New Security Vulnerabilities: Ongoing monitoring and alerting on newly reported open-source security vulnerabilities.
The problem with open-source software security isn’t the software itself—at least not in my opinion. It’s ownership and responsibility. With proprietary software there is no question of who is responsible for addressing any vulnerabilities and developing the necessary patches. But with an open-source project, where hundreds or thousands of developers are contributing to a single platform or application, nobody is truly responsible and, yet, everybody is.

Don’t get me wrong. In most cases and with most open-source applications flaws are addressed and fixes are developed and deployed very quickly. With some open-source code, though, that is not the case. Ultimately, the burden for ensuring that open-source applications are secure falls on the IT managers at the companies using the software.

An even bigger issue than open-source applications themselves is the use of code modules or snippets within other applications. Again, there is a huge benefit to being able to “crowdsource” code and leverage what you need from an open-source community, but if a critical vulnerability is later discovered and fixed in the originating code you also have to take responsibility for updating it in your custom code that uses it.

Jason Schmitt, vice president and general manager for HPE Security Fortify at Hewlett Packard Enterprise, said, “This integration with Black Duck complements our existing secure development and security testing solutions by providing the ability to view the results of open-source scanning alongside application security testing results to deliver a more complete and effective approach to managing application security.”

Open-source software is just about everywhere, which is why IBM, Microsoft, Red Hat, Docker and now HPE all have embraced the Black Duck Hub. Black Duck may not be the only option on the table, but it is the open-source security option that seems to have the most traction right now.
July 28, 2016
Health Care’s Shift to the Cloud via the Hybrid Cloud, Part 1
The changing healthcare scene is dragging hospital systems into the cloud to enable the interoperability necessary for the industry to send electronic medial records (EMRs) and other data to outside systems such as registries that enable bundled payments.

Because health insurance companies and Medicare only pay for patient episodes rather than for each subsequent treatment regardless of whether they’re medically necessary, hospitals must follow each treatment and take responsibility for them all. This gives hospitals incentive to get treatments right the first time.

devopsy.kinsta.cloud paints the landscape behind the healthcare industry’s DevOps-enabled move to the hybrid cloud together with illustrations of how DevOps speeds that transition.

The Old World Order in Health Care

The Old World order for health care dictated that each hospital maintain its own isolated, protected, siloed and closed systems and patient health records, which in the not-too-distant past were maintained entirely in paper documents and charts. “That closed system was a file cabinet,” said Mayank Thanawala, CTO of HealthLoop, a provider of a cloud-based platform to automate follow-up medical care.

Patients likely would have outpatient visits with their doctors at the local clinic adjacent to the hospital. Interoperability between the hospital systems and the clinic systems amounted to hospital staff faxing over the patient record or chart or sending it over via Sneakernet.

A transition still occurring to move all that into EMRs/EHRs (electronic health records), although in a similar model as paper, with closed systems tied to the hospital and local clinics. “These are mostly not cloud systems but are rather on premises with largely client-server topologies,” Thanawala said.

Pain Points Driving Health Care’s Shift to the Cloud

In the old billing model, the hospital or physician billed the patient’s insurance or Medicare for each individual visit and procedure, treating them as separate, disconnected events even when the patient had the same treatment twice for a single need. “Insurance companies and specifically Medicare are now saying, ‘Hospitals, we don’t really care about all these complications, we care about the overall cost. If your patient had to go to the emergency room and had to have you perform the same surgery over again, that’s on you. We’re only paying for that initial surgery,’” Thanawala said.

The result is that the hospital must know whether the patient had additional care or the same care twice for the same need, where they had the procedure or treatment and what that was. A closed system, electronic or paper cannot address these requirements. “That is driving the need for interoperability between systems across different organizations, which is driving the shift to the cloud to handle that need,” Thanawala noted.

Delays in the Industry’s Shift to the Cloud

There is a breadth and complexity to health care that requires a great deal of cloud infrastructure, which is creating delays in the industry’s move to the cloud. Health care and HIPAA regulations demand tight, auditable security, which is easier to achieve with the current on-premises systems. “There’s not a lot of confidence in cloud security. It’s getting better, but hospital CIOs have great responsibility and want to be the kings of their domains where security and control are concerned,” Thanawala said.

At the same time, and because it can be problematic for hospitals to update workflow technologies, the cloud must support legacy connections such as HL7 that are not going away. “HL7 is designed to work within a network. Once you talk about cloud systems accessing HL7, you are talking about site-to-site VPNs for security and developing to embedded older technologies such as versions 8 or 9 of Internet Explorer,” he said.

The fact that the data so heavily affects people’s lives, including life-or-death situations, makes the proper scalability, security, stability, uptime and privacy, as well as all the other goals of the cloud and DevOps, doubly important. “It adds another level of scrutiny and pressure to the move to the cloud,” Thanawala said.

Take, for example, auditing, which touches every piece of healthcare data with such intensity. “From a systems perspective, you have to start thinking about auditing systems and tracking all transactions seven years back, which puts a lot of pressure on logging systems and databases,” he noted.

As for uptime, if a healthcare system goes down, how does it affect life-or-death situations in that moment?

How Health Care’s Transition to the Hybrid Cloud is Unique

“The hybrid cloud gives the hospital CIO the ability to maintain control over what they need to control and still look to the cloud to enable the integration and interoperability with outside systems,” Thanawala said. This is important because of the many factors that make transitioning to the cloud unique in the healthcare industry, including:
- Users in hospitals blame their systems—systems the CIO is responsible for—for any number of challenges and errors.
- Healthcare facilities don’t really have to scale in the cloud quickly, because in health care there already is a defined patient population and facilities won’t have a large number of new users signing up that it can’t handle.
- Service providers must convince hospital CIOs that collaborating with cloud technologies, including opening up VPNs and ports where necessary, is worth the risk.
Digging into DevOps

In part two of this series, we’ll explore how DevOps helps to enable the hybrid cloud in health care.
July 26, 2016
DevOps Chat: GitHub Enterprise as a Hosted Service, with Jean-Louis Vignaud

I recently sat down with Jean-Louis Vignaud, program manager at IBM, about the new GitHub Enterprise as a hosted service that recently was rolled out on Bluemix. The GitHub Enterprise as a hosted service is a great option for enterprises that, due to compliance or other security requirements, cannot used a shared, public GitHub service.

This GitHub Enterprise as a hosted service is the first of its type available and is hosted on the Bluemix service as both on-premises and hybrid environments. You can get more info on this at:

1. Blog : Introducing the first-ever GitHub Enterprise as a hosted service

2. Video : Benefits of GitHub Enterprise with IBM Bluemix Dedicated

3. SlideShare: IBM Bluemix Dedicated – GitHub Enterprise

Also, we will have a webinar that goes into greater detail on this. More info is at: http://webinars.devopsy.kinsta.cloud/scaling-devops-github/

In the meantime, here is the streaming audio file of this chat, followed below by the transcript of our conversation to follow along.

Alan Shimel: Hi, this is Alan Shimel, devopsy.kinsta.cloud, and I’m here with another DevOps Chat. Today’s guest on DevOps Chat is Jean-Louis Vignaud, Program Manager from IBM. Jean-Louis, I hope I didn’t mess up that name too bad.

Jean-Louis Vignaud: No, that’s fine. Thank you, Alan.

Shimel: Okay. Welcome to DevOps Chat, Jean-Louis, and as I mentioned, you are a Program Manager at IBM, and right now anyway, you’re very involved in working on the GitHub Enterprise as a hosted service offering, and we wanted to talk to you specifically about that.

Vignaud: Okay.

Shimel: So, Jean-Louis, I think everyone listening out here is familiar with Git and GitHub, but they may not be familiar with the concept of GitHub Enterprise as a service, so why don’t we start there, if you can explain to our audience a little bit about what that is.

Vignaud: Okay, so maybe we can start with GitHub first.

Shimel: Okay.

Vignaud: GitHub is very well-known, it has probably 15,000,000 users as of today, it’s a very well-known user experience. It’s a collaboration platform, and it’s based on Git, so it’s running on top of Git, but it has many other services on top of Git. And the purpose of GitHub is to provide this collaboration platform that enables people from all around the world to collaborate on a business project, or even a private project.

And that very well-known collaboration platform is very attractive for enterprises that want to provide the same level of collaboration within their own organization. And so what was introduced by GitHub the end of 2011, early 2012 was GitHub Enterprise. GitHub Enterprise is an on-premises version of GitHub. So, same set of capabilities, but you can install it when it’s on-premises in your—on-premises in your environment, and get it working within your firewall. So that enables teams to—you know, to enable organizations and different teams to collaborate among each other in a safe way.

So that’s the background, and where we were standing before we introduced our offering.

Shimel: Mm-hmm, and [Cross talk]—I’m sorry. I didn’t mean to interrupt.

Vignaud: Yeah, so what I was going to say is that, as usual, inside an organization, as soon as you have to install your product, you have to run it, you have to manage it, you have to provision your infrastructure, you have to have the people set up and standing to manage the GitHub Enterprise offering, meaning doing the backup, doing the upgrade, monitoring its running and doing everything that needs to be done in order to comply with the enterprise security requirements.

And that requires time, and most of an inside organization, you know, people are looking to move to the cloud, benefit of the cloud facilities, which they could find in GitHub today, but it’s a public cloud that does not meet the security requirements of an organization, and they would want the same GitHub experience, but within their organization. And this is where we come with our service offering around GitHub Enterprise—providing the user experience of GitHub within the organization while still managed by IBM.

Shimel: Got it. And just to make clear, Jean-Louis, as far as I know, IBM is the only one actually offering this GitHub Enterprise as a hosted service, correct?

Vignaud: Yes, this is a first-of-its-kind offering. I know if you look into what GitHub provides, GitHub provides GitHub Enterprise so you can run it on premise. You also can install it on infrastructure as a service, so you can run it inside AWS, you can run it inside Azure, but there was no one providing a service offering around GitHub Enterprise. So, with IBM, it’s hosted and managed by IBM so the “and managed” is unique.

Shimel: Got it. And another thing I just want to emphasize, because as we were speaking about before we started today’s broadcast was, you know, this is in partnership with Git, right?

Vignaud: Yes, that’s a partnership with GitHub, yes. We announced the partnership at InterConnect early this year in February, and so since the announcement, we have been working and creating this offering. So it took us 12 months to build it and to release it.

Shimel: Understood. And I think that’s important, because you know, it’s one thing to just take some open-source project and offer it as a hosted service, right? Anyone could do that, it’s open source.

Vignaud: Yes.

Shimel: But to really have the cooperation with Git behind this really gives, I think, the best chance for enterprises to have their own Git environment really, truly as a hosted service.

Jean-Louis, I wanted to talk about another aspect of this offering, and that is, as it’s part of an Integrated Bluemix Dedicated offering as well, right?

Vignaud: Yes.

Shimel: So let’s start off with, what is Bluemix Dedicated?

Vignaud: Okay, so IBM platform-as-a-service offering is Bluemix. So, Bluemix, it consists of a huge set of services, for mobile application, for cognitive applications, so about more than 150 APIs organizations can use to build a cloud-native application, to integrate these applications with a back-end system. And so Bluemix is available in the public cloud, but as well, it’s available as a single-tenant dedicated cloud for the customer.

So that’s Bluemix Dedicated. So, meaning, it’s a Bluemix for our customer with all this API, all these platforms that enable you to build and run your application. It’s based on Cloud Foundry, it supports containers, Dockers and so on. So it provides a very extensive set of technology that enables organizations to quickly build applications.

As part of Bluemix, there are a set of DevOps services, so tools we provide to help organizations build those Bluemix applications. And this is where our GitHub Enterprise offering sits. It’s a DevOps offering, part of Bluemix Dedicated.

Shimel: Got it. So, Jean-Louis, this is—I mean, unfortunately, we only have 12 to 15 minutes here, but there’s a lot of layers that we can peel back it of what one can do with this GitHub Enterprise offering, you know? And especially, in my mind—look, if you’re developing applications and you just want to have your whole platform as a service with best-of-breed stuff such as a Git, such as a Cloud Foundry, all of these elements that give you a best-of-breed application development in platform as a service forum, it seems that all the pieces are here to come together. And it’s a great time to be alive. It’s a great time to have to—you know, if you wanna develop applications, to have that at your fingertips.

Vignaud: Yes, and in the context of Bluemix Dedicated, single-tenant, completely integrated with your enterprise network, so it enables you to safely integrate with your back-end system. So you really have a very advanced platform enabling you to develop in a safe way; you know, very innovative applications.

Shimel: Yeah. So, Jean-Louis, two questions for you. No. 1, in terms of advantages of using the GitHub Enterprise hosted versus the public Git, that GitHub that so many of us, I think 50 million is the number of people use—the obvious advantage is, this is a more secure environment, it’s yours only. But are there any downsides? Is there any kind of features not available in the hosted service that would be available in the public service?

Vignaud: No, not really. You know, the GitHub Enterprise has been designed to provide the same user experience as GitHub. I would say that the value of GitHub Enterprise, it’s the user experience of GitHub, but you can run it for you, so it’s a single-tenant for you as a customer, leveraging the cloud infrastructure from IBM, you can run it in a data center where you want to, geographically you can localize it in the country where you belong. So if you have compliance requirements requiring you to host your source code in-country, you can do that.

So, I would say, no limitation and much more flexibility when it comes to the deployment of the offering.

Shimel: Excellent. Next question, I just wanna make sure—is this publicly available today? Because I remember—

Vignaud: It is, yes. It is available today. We announced it on the 17th of June. We officially announced it on the 17th of June, so yes, it is available today, and any Bluemix Dedicated customers can use it as part of the offering.

Shimel: Oh, excellent. And I should also mention, Jean-Louis, that in the near future, actually—I think we’re finalizing scheduling right now—we’re actually gonna do a full webinar with GitHub and IBM, where we’re gonna explore a little deeper into this offering and for those of you listening who may be interested, I strongly, strongly encourage you to attend that webinar.

But Jean-Louis, if people don’t want to wait for the webinar, I know IBM has put up several content pieces where people can get more information from this. One is a blog introducing the GitHub Enterprises service, there’s a video that shows the benefits, and I think there’s also something up on SlideShare about IBM Bluemix Dedicated and GitHub Enterprise. I will try to—

Vignaud: Yes.

Shimel: — yes, I will try to include the links to those when we publish this chat, but again, I strongly—if you have questions about his, if you’re a Git user and thinking you’d like your own GitHub Enterprise dedicated service, I’ll try to put those in there.

You know what, Jean-Louis, unfortunately we’re just about out of time. Is there anything you want to add?

Vignaud: I think this is fine. Thank you very much, Alan, for the interview here.

Shimel: Thank you.

Vignaud: I really look forward to have many customers for this offering.

Shimel: You know, I think it’s something the market needs. It’s good to have that. As I said, it’s a great time to be a developer today, right? So many tools, so easy to use.

Vignaud: Yes.

Shimel: Anyway, Jean-Louis Vignaud, Program Manager at IBM, thanks so much for joining us today, and we look forward to hearing more about GitHub Enterprise as a service.

This is Alan for devopsy.kinsta.cloud. Thank you for listening in, and we’ll see you on the next DevOps Chat.

Vignaud: Thank you.

July 21, 2016
Case Study: Laserfiche Builds Hybrid Cloud for ECM

Laserfiche is a privately owned software development company that creates enterprise content management (ECM), business process automation, workflow, records management, document imaging and webform software. The company provides secure document management, image capture, electronic forms, workflow automation, digital signatures and DoD 5015.2-certified records management, “Automating and streamlining business processes with prepackaged solutions for contract management, HR onboarding and new account openings,” says Thomas Phelps, vice president of Corporate Strategy & CIO.

Laserfiche also maintains a business process library including templates that enable its customers to hit the ground running on new ECM deployments.

The business counts Fortune 500 companies among its customers, serving industries including government, education, health care and finance. “We’re an enterprise content management software leader in state and local government, with a majority of the Center for Digital Government’s top digital cities and counties as our customers,” Phelps says.

This is the story of the company’s addition of a cloud infrastructure and its plans for a hybrid cloud.

Embracing DevOps and its Culture in Preparing for the Cloud

Laserfiche embraced DevOps and its methodologies and tools simultaneously as it began development on its cloud infrastructure, the Laserfiche Cloud, which the company announced in January 2014 at the company’s worldwide Empower user conference.

With that, Laserfiche took a sharp detour from its usual scrum development practices, adopting DevOps for its ability to encompass the development needs and demands of a cloud project.

To use DevOps to move up the timetable on bringing the Laserfiche Cloud to life, the company had to swallow the DevOps culture, tools and processes whole. “We created a separate, dedicated cloud infrastructure team responsible for rapid deployments of test and production environments. We assigned a member of each software product team as a designated Laserfiche Cloud liaison to represent each product team including Laserfiche Forms, Laserfiche Mobile and Laserfiche Connector teams with respect to any feature updates, testing or releases for Laserfiche Cloud,” Phelps says.

Though the Laserfiche Cloud infrastructure development team works in unison, each team member has the opportunity and responsibility to isolate, program and interweave software and services. Proper governance and controls ensure this means progress rather than setbacks for the ongoing cloud project.

Development adopted PowerShell scripts, open-source and homegrown tools and Chef to promote advancement of a DevOps pipeline for its cloud infrastructure.

Software Development Before DevOps and the Cloud

Before moving to DevOps, the company developers relied on scrum-based agile development methods. The process followed from planning two-week sprints, through developer programming on desktop machines, unit testing, committing daily code changes, testing using daily automated builds and ultimately ending with retrospectives. Software products were tested individually by their own teams on separate VM clusters assigned to each team.

That process allowed for one big release per year with smaller releases before and after. “Before DevOps, we manually uploaded release packages to our support site for customers and resellers to download, install and configure the Laserfiche ECM,” Phelps notes.

After DevOps, with the Cloud

The Laserfiche Cloud, a software-as-a-service (SaaS)-based ECM subscription service, offers mobile synchronization, e-forms and workflow automation in addition to its previous services, once offered only on premises. “The Laserfiche Cloud provides robust granular system security, encryption and audit reporting to bring centralized control and transparency to business operations,” Phelps says.

With the cloud infrastructure in place, the company now is using the same DevOps culture, structure, tools and people to develop a hybrid cloud version. “We’re developing a hybrid solution, using Laserfiche Web Access, to provide access to hosted content and enable collaboration with third parties, business partners and customers,” Phelps notes.

Results, Benefits

“Instead of taking days or weeks for information technology or our software testers to deploy new VMs and infrastructure, the cloud infrastructure team can spin up new test environments within hours,” Phelps says.

The company progressed from one major product release a year to updates every one to three months by automating the process of configuring new environments and deploying software. “Many software engineering teams have begun adopting a cloud-first development system where they develop and test binary packages and use internal tools to deploy the packages for testing,” he notes.

Laserfiche can now satisfy customers with larger, swifter feature enhancements to its Laserfiche Cloud. “The cloud infrastructure team works closely with our software engineering teams, using accelerated release management processes, to perform upgrades in hours within an approved maintenance window,” Phelps says.

July 20, 2016
From Pockets of DevOps to Dev-Biz-Sec-HR-QA-Sales-Everything-Ops, DOES London 2016

I am just recently back from London (again) where I attended Gene Kim’s DevOps Enterprise Summit London 2016. To me the theme from this years show is that at so many large enterprises (or horses as Gene calls them), we are moving from the initial “pockets of DevOps” trials to full blown DevOps adoption across the enterprise. This DevOps adoption is even moving beyond just the pure Dev and Ops team to include many different parts of the enterprise. Marketing, sales, business units and even HR are jumping the DevOps bandwagon to perform at higher levels.

Time and time again we saw speakers get up and describe how their organization started with pockets of DevOps adoption 2 to 3 years ago or more and now those successful efforts had been replicated in other parts of the enterprise.The results have convinced other parts of the organization to give DevOps theories a chance.

Of course not everyone agrees that DevOps has a place in the enterprise beyond Dev and Ops. I spoke briefly to John Willis about it and his initial reaction was that he is more of a purist who believes DevOps is still about Dev and Ops, not HR or other departments. I didn’t get a chance to speak to John more about this as it was a busy few days, but hope to follow up with him soon on it.

In the meantime the idea that DevOps starts with a beachhead or pocket of DevOps is one we have heard before. Carmen DeArdo of Nationwide has talked about how he has helped lead Nationwide’s DevOps transformation by picking a few smaller but important projects that generated visibility for the rest of the organization to see that DevOps does indeed work.

Of course Carmen is not alone in the concept of pockets of DevOps. We have heard similar from folks like Gary Gruver in his “Leading the Transformation” book, Damon Edwards and others espouse this approach. What is interesting to me though is the follow through we saw at DOES.

I think we can all imagine that if DevOps works in a few projects, we would see it rolled out to more Dev and Ops teams. What I think was really surprising was that it doesn’t stop there. The fundamentals and principles of DevOps are proving to be useful beyond the borders of developers and sys admins.

One could say that it would be easy to see how adjacent players like QA and security admins would also see the benefits of DevOps. But as we saw at DOES London even HR and other business units are joining in the DevOps fun.

This goes to something I have been saying for some time. While DevOps certainly originally referred to Dev and Ops, it seems to have outgrown the original intent. Maybe this is due to the fact that we never had a real definition or manifesto. In failing (not sure failing is the right word even) to do so, DevOps has been given a little more freedom to expand into areas that perhaps no one really thought it would. To me DevOps has become an umbrella term to refer to “the new way things get done”.

Now granted this may not sit well with John Willis and some others. I respect that they have a more narrow view of what DevOps is and what it is supposed to be based upon their years in the trenches evangelizing and helping to drive DevOps adoption. However, as I said I think it has grown beyond that and at least some of that is due to the hard work that people like John Willis, Patrick Dubois, Damon Edwards, Jez Humble and others have put in over the years.

There were many sessions and speakers at DOES London on a wide range of topic as well. We did almost 40 video interviews that will be available on our YouTube channel, DevOpsTV. There will be a separate playlist for DOES London 2016. More videos will be added to that as soon as we receive the approvals from the participants. In the meantime I wanted to show you one with my friend Helen Beal of Ranger 4 and Soren Pederson of Lego.

July 18, 2016