devopsy.kinsta.cloud

Category: Features

  • Cobalt Merges Bug Bounties, Continuous Testing for Better Security

    Cobalt Merges Bug Bounties, Continuous Testing for Better Security

    The rapid pace of application development today can be hard to keep up with, especially when it comes to security. Combining the benefits of continuous testing with the incentives of a crowdsourced bug bounty program seems like a potentially effective way to address that volatility effectively.

    Companies need to keep up with demand while staying one step ahead of the competition. It’s very easy in such a dynamic environment for security to fall through the cracks, or be ignored entirely. Combining DevOps-style automation with crowdsourced intelligence is a good approach.

    Bug bounty programs have matured and gained mainstream acceptance in recent years, thanks in large part to the leading champion of bug bounty programs, Katie Moussouris. After launching Microsoft’s successful bug bounty program, she left to join Hacker One as Chief Policy Officer. She recently ventured out on her own as a bug bounty evangelist and consultant under the banner of Luta Security.

    The concept is simple: Rather than pretending vulnerabilities don’t exist, or sitting around waiting for the bad guys to exploit the vulnerabilities first, a bug bounty program provides financial incentives for hackers and/or security researchers to identify and report flaws. The net result is a win-win-win that results in more secure applications, happier customers and satisfied security researchers who feel appreciated—and paid—for the work they do.

    That is where Cobalt comes in. “I’m impressed by how Cobalt has built its model by taking the best elements from the bug bounty space, which offers rewards to those in the security community who can identify software vulnerabilities, and combining them with a scalable, continuous penetration testing platform,” said Robert Fly, an investor and advisor with more than 15 years of application security experience from Microsoft and most recently Salesforce, where he built the product security team and was VP of Security Engineering.

    “Companies building web and mobile applications need the flexibility to quickly develop new applications that delight their customers, while ensuring that their applications are secure,” said Jacob Hansen, CEO of Cobalt. “Instead of needing to invest in security tools, such as scanners and penetration tools that are expensive and vary in quality, and having to hire security staff or consultants, our customers rely on Cobalt to provide transparent continuous application testing services, leveraging a powerful platform along with a global community of security researchers.”

    There are a variety of well-known software-as-a-service (SaaS) companies already using Cobalt, including GoDaddy, Wix, Weebly, Nexmo and Optimizely.

    At face value, this seems like an awesome strategy. Only time will tell how it really plays out, but the success of bug bounty programs when it comes to finding and fixing vulnerabilities in general is indisputable, and continuous testing is a staple of DevOps environments. Combining the two should raise the bar for application security in general.

  • Vivint Meets Smart Home IoT Challenges Using DevOps

    Vivint Meets Smart Home IoT Challenges Using DevOps

    Smart home technology vendor Vivint  serves more than 1 million U.S. and Canadian consumers with services including broadband internet, cloud storage, home automation products, home security services and energy automation controls.

    The company, which got its start in home security, leverages door and window sensors, motion detectors and glass-break sensors, as well as those that detect flood, heat, freezing, smoke and carbon monoxide in the home, said Nick Brown, director of Platform Architecture at Vivint. “We have a bunch of indoor and outdoor cameras such as doorbell cameras and the ping camera that is an interior camera supporting two-way audio.” For the smart home, Vivint extends automation devices, intelligent thermostats and Amazon Echo into the household.

    Vivint used DevOps to get the software platform behind these sensors and smart home devices up and running within a year. Vivint continues to use DevOps to meet the needs of its growing platform.

    Building a Software Platform for the Smart Home

    Vivint started its expansion from home security company to the largest smart home provider with a challenge of growing a platform that could serve a million customers. This was necessary to fold in the 700,000 home security customers it already had in with the 200,000 new smart home customers its leadership knew were coming in a matter of months.

    “We were building this new infrastructure from absolutely nothing and we needed to support 200,000 new installations in the first few months of operation,” Brown said. Vivint had its existing home security customers on a legacy platform supported by a third-party company; that company had a full 10 years to build out its infrastructure. Vivint had one year to bring those 700,000 existing customers into a new system and less time than that to prepare for the influx of new customers.

    Vivint accomplished its goal, serving more than 900,000 homes in the first 12 months.

    What DevOps Now Accomplishes for Vivint

    DevOps enables Vivint to manage stateful and historical data at scale, Brown said, which allows the company to power the biggest smart home platform in the world. Customers see everything that is going on in their house, including current and 45-day history of what happened, through a 7-inch control display.

    The real value the Vivint platform provides is in the integrated in-home experiences, which the company virtualizes and makes available anytime, anywhere around the world, giving customers a real-time view into their home data, he noted.

    To build, use and evolve this platform, Vivint uses MongoDB, RabbitMQ, Nginx, ELK (once the ELK stack, now the Elastic Stack), Salt and homegrown tools. Vivint applies its homegrown code to the task of guiding a communication protocol that enables the smart homes and the Vivint cloud to talk to each other.

    The company uses RabbitMQ, an Erlang language-based open-source message brokering tool that supports Advanced Message Queuing Protocol (AMQP) to disperse those messages in and out of its software platforms, driving them to and from Vivint’s services in its internal infrastructure. Vivint uses Nginx, a multifunction web server/reverse proxy server to serve web applications and services.

    Vivint runs an ELK stack, which consists of Elasticsearch, Logstash and Kibana for monitoring. Its ops team uses Salt, a Python-based configuration manager to manage everything. “We’re looking forward to adding Kubernetes as a new infrastructure solution to make this a little more modular,” Brown said.

    The DevOps Path to Modularity

    Vivint needs its software platforms to be as modular as possible. “Each piece of the infrastructure must support a modular paradigm. Because we are following a high-risk, urgent schedule, we need to make sure that any mistakes we make along the way are easy to tear out and replace,” Brown noted. Vivint uses virtually countless services to make this possible while pushing out weekly software releases.

    “From a DevOps perspective, we have a lot of things to manage here,” he said. Vivint uses AWS to support its infrastructure in the cloud and the company has its own private cloud as well. Vivint needs to move safely and quickly while retaining its agility and orchestrating all these different elements.

    To bring all the smart home technologies into the new system, Vivint chose MongoDB because its data models and code tend to naturally mesh with the data models in that database. “We took advantage of the flexible schema, and the document-oriented architecture of Mongo really allowed us to write very little data access code,” Brown said. This significantly cut back on implementation time.

  • Simplify and Streamline Hybrid Cloud with DevOps

    Simplify and Streamline Hybrid Cloud with DevOps

    The cloud is not new. The virtues of the cloud have been proclaimed incessantly for years, and most businesses have embraced cloud servers and services on some level. The realities of data security and the need to leverage existing investments in IT infrastructure, however, generally result in some sort of hybrid cloud setup, with servers and applications that span both local data centers and cloud providers. Hybrid cloud deployments can be complex and volatile, which is where DevOps comes in.

    I wrote a report recently for DevOps.com that takes a closer look at the pros and cons of hybrid cloud, and the symbiotic relationship with DevOps. “DevOps Enabling the Hybrid Cloud” examines how DevOps tools and practices streamline management of such an environment. It also looks at some of the security implications and how DevOps can address those concerns.

    The report explains, “Speed and flexibility are imperative for organizations that want to remain competitive. Organizations that strive to lead understand that IT must be viewed as a strategic advantage—a powerful tool for driving innovation and creativity. The hybrid cloud provides a bridge from legacy hardware and assets to cutting-edge concepts such as containers and serverless computing for organizations that do it right.”

    One truism addressed in the paper is that customers—whether they’re external customers of your company or the users within the company that rely on IT services and applications—don’t know or care where your applications or data are delivered from. They know that they want stuff to just work when they need it to work. It’s up to IT to determine the most efficient and effective way to achieve that goal, and to provide a seamless, frustration-free experience. Sometimes that means relying on cloud servers and services, and sometimes it means using local infrastructure.

    I spoke with Justin Foster from Trend Micro about the overlap of hybrid cloud and DevOps, and specifically about unique security issues with hybrid cloud environments. He stressed that legacy tools and traditional approaches to security are not sufficient for the more dynamic hybrid cloud environment. As explained in the report, “Security has to be baked in from the beginning and throughout the development life cycle.”

    A pure cloud infrastructure is unlikely for any established company. It may be achieved eventually through attrition, but there’s no getting around the fact that there already are servers and applications in place. The hybrid cloud approach is the right solution in most cases, and DevOps tools and practices are essential to help manage and secure the hybrid cloud effectively.

    Click here to download the report: “DevOps Enabling the Hybrid Cloud.”

  • DevOps Chat: John Harris, LeftShift on DevOps Consulting and Continuous Testing

    DevOps Chat: John Harris, LeftShift on DevOps Consulting and Continuous Testing

    This episode of DevOps Chat has us speaking with John Harris of LeftShift IT. LeftShift is based in London, but has customers the world over. He speaks with us about DevOps consulting and continuous testing. John has some great insights to share that I think you will find interesting.

     

    Alan Shimel:                Hi, everyone. Alan Shimel – DevOps.com here for another DevOps chats. This episode’s guest is John Harris of LeftShift IT. John, welcome.

    John Harris:               Thanks, Alan. Good to be here.

    Alan Shimel:                Thank you. So John, what exactly is your role with LeftShift 

    John Harris:               My role is the Head of Continuous Delivery in DevOps with LeftShift.

    Alan Shimel:                Okay. And John, you know what? Some people in our audience are probably not familiar or may have not heard of LeftShift IT before. Why don’t you give us quickly a background of LeftShift?

    John Harris:               Yeah. We’re primarily a services consultancy in the continuous delivery – DevOps continuous testing space. We work quite a lot with IBM, a lot of other different vendors. Based in London and the UK, but we have a lot of our business offices based in the U.S. as well.

    Alan Shimel:                Sure. And John, before we jump into the subject of today’s chat, which is around continuous testing, I want you to take a moment and just talk about this burgeoning field of DevOps consulting. It seems to be exploding. I was in London for the DevOps Enterprise Summit last month and I was absolutely blown away with the diversity of firms from big to small that are offering DevOps consulting services. How long has LeftShift been in the DevOps consulting space?

    John Harris:               We’ve been in the area kind of on and off I guess you could say ten years. I guess most people would say DevOps has only been around since that original kind of DevOps coining days again in Belgium, but I guess a lot of people say the discipline itself had been around before the name, so I guess the processes around DevOps you could say we’ve been involved in for quite some time I guess. 

    Alan Shimel:                Sure. And John you know I don’t think we would be seeing this explosion of DevOps consulting if there wasn’t a wanting audience for DevOps consulting continuous delivery consulting services. Is that pretty much what you’re seeing with LeftShift? I assume business is good.

    John Harris:               Yeah. It’s one of those interesting areas where one of the things I guess the DevOps consultants could say is you don’t just want to create a new DevOps practice in your company. You don’t just want to bring in these pieces, but it’s a difficult loop because you’ve got to then support those processes and you’ve got to get that knowledge into the organization somehow, so I think our model is firmly to go and help people get started and gussy up their own practice and their own good processes and then kind of lead them to it, so yeah absolutely.

    Alan Shimel:                Got it. So John, let’s pivot a little bit here and talk about continuous testing. So, I will tell you that on DevOps.com the whole notion of testing, continuous testing, automated testing is one of the most hotly debated and in some ways controversial topics within DevOps. Wondering if you see similar?

    John Harris:               Yeah. I think so. I mean I think traditionally in so far development, testing has traditionally kind of been seen as just the necessary part that you have to do at the end, but I think now that continuous delivery is becoming a real discipline and people are being forced to go faster and faster for getting ahead of the market and things like – can’t afford to see testing as a poor cousin of development anymore and I think testing is really becoming – people realize I can throw stuff out into production as quick as I want really, but actually it’s throwing it out with the quality that it needs to – that product to still be viable in the market. So I think absolutely. The drive towards testing is long overdue, but it’s definitely getting started. 

    Alan Shimel:                Got it. And John, can you have continuous without the automation though?

     John Harris:               Personally I don’t think so. I think that DevOps really – one of the biggest buzz words for me – DevOps and continuous delivery is really the organization. I think you have to have the process behind it, but I think when you go towards anything delivering more rapidly through all of these stages in our development life cycle in production, I think you just cannot scale at the size that we need to in order to get that stuff out without automating the process.

    I mean when you talk about the union it forms like Netflix and Etsy and all of those guys, now three, four years ago, there’s no way you can deliver that kind of scale without putting in the automated tool in and also the processes and the culture around that to enable that to where it will have the effect that you need.

    Alan Shimel:                Sure. So John, I think one of the controversy – not controversy, but one of the big discussion points around this though is what does this mean for the traditional Q/A role and for the people in the Q/A space?

    John Harris:               Yeah. I think teams have traditionally kind of been split. I mean obviously we have these silos and DevOps as kind of trying to address the silos of development and testing and ops and those kinds of things. I think again, testing’s one of the things that gets left out of that, but certainly in the customers that we work with, we’re seeing a lot of Q/A teams being retrained in certain ways, brought into the development side of the organization, having their practices changed to more of a development software engineering kind of way of working.

    We’re certainly seeing some of the geographic splits that have been traditional in this area kind of being broken down, perhaps testing, quite a lot of off shoring work in testing. Some of that’s coming on shore. Testers are becoming more technical but yeah, retraining and the different skills required now for the Q/A role, to bring that into more of a technical automation. That’s certainly a question a lot of our customers are grappling with right now and I think the decisions they aren’t just technical, but they go into the culture side of the company and how the company has organized itself. So yeah, it is a contentious area. I agree.

    Alan Shimel:                Yeah. It certainly is and it’s really one of those – for people in the Q/A space, it’s a pocketbook issue, right? They perceive a threat to a livelihood, even though I don’t think that’s the case. I think it allows them actually to soar and higher and do bigger and better things, but there’s certainly that element to it.

    John, I want to talk for a moment about service virtualization and we actually have a webinar coming up on I think it’s August 23rd where we’re going to looking at a real unicorn company – Mertz Shipping Lines, which is I think is 80 years old or something in traditional shipping, not what you would think of as your Google, Facebook kind of company. But they’re going to be talking about service virtualization, shifting left. Thoughts on that at all?

    John Harris:               Yeah. Service virtualization is an area that we work with quite a lot, especially around the IBM tool set. And yeah, Mertz is doing great work. Almost all of the organizations that we work that are trying to do some kind of parallel development, I mean one of the patents that we see is building the y and Rex API layers on top of some of their legacy – so business services and things like that and they want to do some parallel development with the ____, with the Rex, with the user in space layers. So SV’s really able to give those teams a really solid platform because everything’s based on their service interface definitions and it can really do some proper parallel development there and we’re seeing some great shifts left with those development teams and actually the ability to identify a whole bunch of defects before they would even go and integrate with each other.

    I think we had one team who identified over 100 defects in the early testing stages using service virtualization before they even would have integrated with the other services. They were able to get those fixed even before they went into their next integration environment, so that was a really great success story – service virtualization. 

    Alan Shimel:                Yeah, absolutely. I think I interviewed the Mertz guys at Interconnect last year and it was an interesting case study. I guess we should mention – there is a Service Virtualization for Dummies book that people can download and I don’t have the URL in front of me. I’ll try to include it in our notes. I think it comes out from IBM for people who are interested in this. But John, let’s return – what do you see – what in your role with LeftShift, what do you see as sort of the next frontier where the – not the battle, but where there are points to be made, where there are battles to be won for lack of a better word in the near term future?

    John Harris:               I think the biggest one really and we’re starting to see the shift now, but it’s still early stages and the custom is that – for the unicorns and the startups, this is probably not going to be a big bull, but certainly for enterprise – user interface testing is still very prevalent and we talk about the testing pyramid how most of our tests are one of the unit tests and then we’re gonna have a good base of integration tests and then a small percentage of UI test if you want.

    I think currently a lot of our organizations have one of them that’s flipped on its head because it’s easy to do UI testing and reason about it going to the business, but now when we go faster, I think the traditional focus on UI testing is going to have to go away, but when we talk about APIs on top of everything and things like the API economy and a lot of systems now just don’t have UIs. Coming out with a lot of systems that are all API driven and smart devices.

    I think everything’s going to have to be integration tested. I think the APIs and the logic behind them is really where the core business functionality is, so I think that’s where the importance is gonna be and it’s going to be moving organizations and showing them that integration testing and API testing is not the way to go and obviously automating that as part of their delivery pipeline, which is sometimes a little more difficult to do on the UI side.

    Alan Shimel:                Yeah. Quick question on that because I thought about how to deal firsthand with this issue. Shouldn’t the API testing – at least the tests themselves come from the same people who are writing the API? In other words, where’s the burden? Should the people who are providing the APIs also provide the testing for it or is that sort of letting the wolf in the chicken coop, right? Where you’re using someone else’s API. The burden is on you to make sure that that is in fact working with your system.

    John Harris:               Yeah. That’s a really interesting point I think and there are different kind of philosophies around it. Myself, we work a lot with the virtualization and the testing side of it, so we would say that if you’re developing the interface then you’re also in charge of developing the basic virtual service for that to integrate with your consumers, but I’m very much on the side of consumers developing the API test or the APIs that you consume, because if you think about the case where I’m a consumer, I may not need every field in an API. I may just use a few if I’m developing loosely coupled micro services let’s say.

    So I’m really in favor of each team who consumes an API developing their own tests and then contributing those tests to the API team so they can be run as call, every build or every deployment. So then if I change functionality and those tests fail, I know which team gave those tests to me and I can go and alert them, “Well, look I’ve made a change and I’m just going to break your implementation or your call of this API, but I may not have broken anyone else’s.”

    I mean I think putting the burden to test every piece of functionality, especially as we go to more loosely coupled services is kind of an unreasonable burden on the team developing that API.

    Alan Shimel:                Got it. You know what, John? Believe it or not as I told you I think before we went live, time goes really quick on these and we’re coming up on the end. If someone wants to find out more about LeftShift, where can they go?

    John Harris:               I think it’s LeftShiftIT.com and we’ve just revamped out website, so they can find out all about our services and products and everything we offer on there.

    Alan Shimel:                Okay. And then finally John, I wanted to end with the kind of question I guess I ask just about every guest, which is for our audience out there, if they’re gonna read, what should – if they –hopefully if they do read everyone should read books. What do you recommend is the next book our audience reads?

    John Harris:               I’m a big Jez Humble fan and I’m not going to recommend Continuous Delivery, because I’m sure everyone’s read that who’s listened to the podcast, but is Lean Enterprise book – How High Performance Organizations Innovate at Scale and it’s Jez Humble, Joanne Molesky and Barry O’Reilly is an awesome book for any enterprise looking to get into this kind of area.

    Alan Shimel:                Absolutely. I actually have it on my book shelf in the office. Good one, John. Anyway, I think that’s gonna use up our time here on this edition of DevOps Chat. John Harris, LeftShift IT, thank you very much for being our guest and we look forward to hearing more about LeftShift and continuous testing service virtualization going forward and continued success.

    John Harris:               Great. Thanks for having me, Alan.

    Alan Shimel:                Thank you. This is Alan Shimel for DevOps.com and DevOps Chats. Until next time, have a great day. 

  • Case Study: Stytch Before, After DevOps Culture, Tools

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

  • DevOps Q&A: SUMO Heavy’s Brodie on the Hybrid Cloud

    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.

  • Citizen Developers Can Benefit an Organization

    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.

  • The Big Shift: The State of Continuous Delivery

    The Big Shift: The State of Continuous Delivery

    The state of continuous deliveryI wanted to call out a new report that we have just released here at DevOps.com. The State of Continuous Delivery: The Big Shift by George Hulme, contributing editor here at DevOps.com.  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.

    DevOps.com Reports

    This is the first in a new series of reports that we have been working on here at DevOps.com. 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.

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

    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.

  • Black Duck, HPE Partner to Protect Open Source

    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.