staging-devopsy.kinsta.cloud

Category: Features

  • Cloud or In-house with Chris Kinsman, Part 2

    Cloud or In-house with Chris Kinsman, Part 2

    I sat down last week with Chris Kinsman, Chief Architect at PushSpring and a 20+ year veteran of software development, to talk about the factors that go into deciding when to migrate to the cloud. In Part 2 of our conversation we talked about the resistance and arguments against moving to the cloud. Once again I’ll let Chris do most of the talking:

    “What I struggle with is those companies who are trying to decide whether they go to the cloud or not even attempt it. For someone starting out, I don’t think there’s any choice – unless there is one specific requirement that pushes you out of the cloud. Or, and this is a little different, they may be evaluating a new project in an existing company. If you’re an existing company that has in-house already – whether it’s co-location or your own data center and you’re already invested in servers and storage – then the default always seems to be continue as is.”

    Well, if the business has existing business with the in-house model, to the extent that they’re successful with that model they may be hesitant to impact that revenue stream.

    “Maybe or maybe not – it could be that you’re just selling a service and they don’t really care whether it’s your hardware or someone else’s. As an example, if you’re paying for a $50/month MailChimp subscription do you really care whose equipment it runs on? Because you’ve already bought into that whole idea of paying for a service and not really caring about what’s behind it. So if I already have in-house infrastructure, at what point do I transition to the cloud, and that might be a more gradual decision.

    One common justification for remaining in-house is avoiding any forced migration. While it’s true that the cloud can – and will! – upgrade your infrastructure, you can also use the cloud to run whatever you want to run.

    “As a consumer of a service bus, I don’t care if they’re running it on 2008 or 2012. As long as it provides the same service, I don’t care what they run under the covers and that’s the beauty of it. Because if I care, that means I have guys in my org who are worried about that that I’m paying to worry about that, and how to keep up with that schedule, and everything else.

    So let’s go back to machine instances. That’s where it’s now on me to maintain, care about migration. And that’s also a choice. There are services that allow me to run my service as service bus, i.e. if I’m running Azure websites, I’ve got a way to get deployed – I need to make sure that my code runs – but I shouldn’t care what server OS they’re running. So these machine instances, that’s the difference between Platform as a Service (PaaS) and Infrastructure as a Service (IaaS), and Infrastructure as a Service. A lot of folks gravitate towards IaaS because they give up LESS control – they haven’t totally abdicated. But the problem I’ve found is that while that’s an easy baby step to lift and step your infrastructure from your internal data center into the cloud, that’s not really taking advantage of the Cloud. That’s continuing to do the thing you’ve always done, just with a machine that’s somewhere else. And I would also argue that that’s not the way you’re going to realize cost savings by moving to the cloud – because you’re continuing to do things the same way you did them before.”

    So, what are the cases you’ve seen where someone should not be using the cloud?

    “This is controversial, but I can think of a few. Where technology is not their primary business. Where they are potentially in a declining market. Where they’re not rolling out new software, they’re not trying to gain new users. They’re just rolling something along to the end of its product cycle. They don’t need scalability – they just want the absolute lowest cost. They don’t even really care about the experience of the users. Then, absolutely find the lowest cost place to host your server. But when I look at people who are making their money off of software, who are trying to grow their customer base and get more users, it’s almost never the right decision.

    And that’s not just me saying that. I saw a stat the other day that 10 years ago, for an Internet startup 80% of their Series A money went to infrastructure. Today, if you tried to pitch a VC that 70-80 of their money would go to infrastructure they would never fund you. They fully expect that 70-80% of their investment will go to salaries for the individuals who are building the product.”

    How about a more mature operation already hosted in the cloud? Is there a point where, for cost or other reasons, it might make sense to move to an in-house model?

    “Even those middle stage startups, I’d say help me understand your case. Maybe their case is they’re doing real-time something and they’re very sensitive to latencies. But I’d say that even guys who are doing VOIP are starting to do more virtualization – and VOIP is about as latency-sensitive as you can get when you’re actively listening for any pauses. So what are those cases? Perhaps there are some out there, but I haven’t encountered them.

    Take telemetry, if you’re a company going out with an Internet of Things story – you’re the next FitBit, or a wearable, or put data collection of your car in the cloud – all of those business models are built on the cloud.”

    Well, you used to work for casinos. They have massive data, real-time needs, and obviously super-tight security. What about them?

    “There I can see a lot of resistance to moving to the Cloud. Legally there are some issues. They are very controlled by the gaming authorities – so maybe there are some barriers they have to push through. But I look at some of the challenges they also have – one of the things I thought was very interesting when I worked for them 10-15 years ago was progressive slots, which were one of the “big things” at that time. Where a bunch of machines were aggregated against a single jackpot. And this required dedicated T1 and T3 lines back to the slot manufacturers so they could do this real time aggregation of data and real-time payouts. That would obviously be so much easier if you could do it in the cloud. So the questions would be could you get this past the gaming commissions and could you make it secure enough. Well…Amazon right now is building a Cloud facility for the CIA, if they can convince the CIA to use the Cloud…”

    But you’ve seen the movies and read the stories – they make you think that the CIA is run by clowns. Of course the conspiracy side of that is they want you to underestimate them, but still it makes you wonder.

    “I go back to argument I made earlier. I have a hard time believing that an environment set up in the cloud is any less secure than your data center that’s connected to the Internet. In fact, it’s probably more secure.

    I think the thing that security guys are concerned with is their whole strategy in the past has been how do I wall everything off? How do I provide defense in layers? At the point where more of your infrastructure is shared, it becomes harder to know where those walls are being crossed, which makes them more and more uncomfortable. But the challenge is, what if a competitor figures out how to do a secure solution in the cloud? There’s a real possibility that they traditional technology folks may not be in business down the road because the costs of operating in the Cloud will be so much lower. And that’s what’s going to end up happening – those guys who are staying in-house, staying with their co-lo, and some point in time there’s going to be some startup that says “we’re going to be disruptive, we’re going to blow up this entire industry, we’re going to look at it differently, our cost basis is going to be so mucfh lower for providing this service that will out-compete them. And over time, that incumbent goes away.

    We’ve seen that again and again, where it isn’t even a brand new business. Heck, Amazon – selling books is not a brand new business – it’s a really, really old business. But they came in and did some pretty interesting things driving their costs way. And figuring out all those things they could do to bring on additional ancillary revenue. What happened to all those big booksellers?

    Or shipping. Look at Fedex, the whole concept that someone could build an airport outside a city in the Midwest…and now the Post Office is almost out of the business of delivering packages.”

    So if you are not actively and continuously thinking about how to use the advantages the cloud can provide, then you are living on borrow time.

    “Exactly”

  • Rugged DevOps: From Idea to Automation to Impact

    Rugged DevOps: From Idea to Automation to Impact

    The Idea Behind Rugged DevOps

    josh cormanWhereas DevOps is IT at ludicrous speed, Rugged DevOps is a shift left to find a way to inject security into DevOps from the beginning, says Joshua Corman, CTO, Sonatype and Rugged DevOps founder.

    One way to do that is for Rugged DevOps to establish security parameters and requirements, meet those requirements as the project progresses, and establish and enforce the automated application of new and existing pen tests on software as development teams deliver it to the internal staging environment, in order to confirm software quality.

    Automating Pen Tests? Running the Guantlt Is One Way

    Guantlt is a project and a platform for doing just that: developing tools to hook into pen tests and run them on internally-staged code. The Gauntlt project works to automate security testing using established tools, to disperse standard errors, and to fail code based on test results and software requirements. “The goal is to provide an automated way to attack your software because, what we need in DevOps is to find ways to automatically enforce security quality,” says Aaron Cois, Researcher, CERT Division, Software Engineering Institute, Carnegie Mellon University.

    The industry is developing frameworks such as Gauntlt to support autonomously running pen tests on every newly staged release candidate in order to avoid involving or requiring any manual effort. These frameworks enable an automated system to run unattended tests up to several hundreds of times a day to keep step with as many potential new releases each day. We can’t expect limited human capital to run that many tests in succession. “We want coders to write that automated test once and then go off and do something creative that we haven’t already done,” says Cois.

    All this is necessary to meet security quality standards while maintaining the shortest time to deliver each new release candidate with the confidence that development could release it to production at any time. “We want to fire off Rugged tests against that internal environment. Having that parity environment is what enables the development of more comprehensive and more interesting testing from a security perspective,” says Cois.

    Teams must run pen tests on running code in an environment that mirrors production. That’s the only way to know whether the software will stand up to attack. Teams must be able to add new tests as new threats appear.

    To automate a response to pen test results, coders write conditional ‘if-this-then-that’ rules into Continuous Integration to respond to conditions such that, for example, when any unit test fails, the system fails to build the software. “A lot of organizations start out by saying, well, we’re going to start writing security-focused unit tests and security-focused integration tests, getting our QA department involved and our Integrated Security Department involved early in that process, having them rating those tests and enforcing tests in Continuous Integration,” says Cois.

    Impact: Rugged DevOps in Action

    “Heartbleed and Shellshock were high-profile vulnerabilities that had been present in BASH and Open SSL for a long time and we didn’t know about them. We had to find ways to make sure we weren’t vulnerable to those,” says Cois. Using Rugged DevOps, the security team member can create tests for such new threats and require the tests using CI. As CD quickly fixes bugs, so Rugged DevOps can quickly defend against new threats.

    One hope for Rugged DevOps is that it will bring truly secure coding even to COTS software as DevOps eventually envelopes all software development. DevOps should enable developers to continue to develop COTS software cheaply while adding the inherent security that would prevent a lot of the successful attacks on software that trouble industry today.

    “I don’t know that we will reach that stage quickly since it certainly requires an investment,” says Cois. There first has to be that continued uptake of DevOps approaches and those changes in processes, culture, and mindset. Rugged DevOps has to accompany that or the eventuality of cheap and secure COTS software might never materialize.

    Concluding Remarks

    “People like DevOps because the concrete hasn’t dried yet and people are copying high performers. At the same time, programmers are assembling 90-percent more code from existing open source code,” says Corman. This is good news where those high performers and those who follow in their footsteps fail faster, fix errors sooner, and carefully consider security at every step, as this will magnify secure code. But developers have to build using the higher quality code those high performers are creating, says Corman.

  • Containers: Secure or Not, Here They Are

    Containers: Secure or Not, Here They Are

    Containers are here. And it doesn’t mater whether or not containers are a transitional technology (they are, as our JP Morgenthal covered in Containers are designed for an antiquate application architecture) until all applications are designed for cloud and web-scale, containers will be part of the cloud and virtualization scene. Right now, containers are white hot. And as you’ve seen here in the past month, containerization was an editorial focus for us throughout March.

    To give you an idea of how popular containers are right now, consider…

     

    –THIS STORY HAS BEEN MOVED TO CONTAINER JOURNAL–

  • Chef defines the DevOps workflow with Chef Delivery

    Chef defines the DevOps workflow with Chef Delivery

    At ChefCon today Chef made a major announcement unveiling Chef Delivery a “new DevOps workflow product that for the first time enables the continuous delivery of infrastructure, runtime environments – including containers – and applications.”  Chef has examined the use success patterns of many of its thousands of customers to distill what they believe is the formula for success in a DevOps environment.

    alex ethierI had a chance to speak with Alex Ethier, VP of Product and Jay Wampold, VP of Marketing at Chef about Delivery. They were both really jazzed as they think this is a real game changer for not only Chef but the entire DevOps market.  Chef is already a leader in the DevOps community with a rapidly growing base of customers in the Global 2000 and a dominant adoption position among AWS customers. Delivery will extend the Chef platform into the entirety of the DevOps workflow.

    Chef believes this is the time to expand the Chef platform to the entire DevOps workflow. Just about every analyst firm and survey data indicates that DevOps is on the way to wide spread adoption among IT teams of all sizes. While DevOps is about cultural change, once the organization recognizes the advantages to a DevOps culture, tools that leverage this culture are sure to expand their footprint.

    I asked Alex and Jay if Delivery would bring Chef into competition with other DevOps tool vendors. For instance Jenkins and CloudBees in the CD and CI area would seem to be square in the cross hairs of Delivery. While on its surface this would seem to be the case, Delivery is actually a platform that is designed to leverage APIs and open source to to work with a large ecosystem of 3rd parties including Jenkins, CloudBees and other players in the DevOps ecosystem.  I am still not 100% sure where the cooperation will end and the competition will begin, but I guess we will have to wait and see how that shakes out.

    Based on Chef’s customer experience research they think this is what the flow of DevOps looks like:

    chef pic
    DevOps lifecycle step by step

    Some steps are and will remain manual. Chef is seeking to play in the automated areas. Yes this is an ambitious move by Chef. If they succeed they will leverage their already dominant position in the DevOps configuration management field into becoming a dominant player in the entire DevOps life cycle.

    Powering this life cycle is the fact that with the move to the cloud today’s enterprises are moving from static systems to rapidly changing services. This is putting new pressures on IT departments to perform in a “high velocity IT” manner. The key to all of this is of course automation. Under it all Delivery seeks to automate CI, CD and continuous testing.

    Chef’s CTO, Adam Jacob had this to say about Chef Delivery, ““The tools we use reinforce the behavior; the behavior reinforces the tool. Thus, if you want to change your behavior, change your tools.”

    Other highlights of Chef Delivery from the Chef press release are:

    • Robust Pipeline: Chef Delivery provides a shared pipeline and proven workflow for software development that safely takes code from a developer’s or operations engineer’s workstation through build, test, and production.
    • Platform for Collaboration:  Each step of the Delivery pipeline incorporates automated testing to provide developers, operations engineers, compliance and security officers, and IT architects rapid feedback on proposed changes. The common workflow allows personnel of each IT discipline to work together with full visibility into the flow of changes through the pipeline. Policies can be easily applied at each step to ensure maximum change control and governance.
    • Sophisticated Analytics: Chef Delivery provides metrics for all stages of your development pipeline. With full audit capabilities, you can track both pipeline performance and activity, manage permissions and access comprehensive change history from easy to use dashboards.
    • Scalable Architecture: Chef Delivery was designed from the ground up for performance and scalability. Its architecture is fully integrated with the Chef Server and designed to meet the demands of the largest and most complex enterprise IT environments.
    • Full Ecosystem Integration: Chef Delivery integrates with an extensive array of operating systems and runtime environments, including public cloud platforms such as Amazon Web Services and Microsoft Azure, as well as runtime environments such as Docker containers.
    • Availability: Chef Delivery is currently available through an invitation program
    • Pricing: Chef Delivery will be sold in 2015 on a subscription basis.

    This could indeed be a real game changer for already high flying Chef.  While at ChefCon today I intend to ask many of the partners and vendors exhibiting here how they view Delivery and what kind of integrations we can expect to see from them for it.

    One thing for sure is the DevOps tools market is evolving and maturing rapidly.  Tool vendors will have to move quickly to allow high performing IT teams to move at the speed of DevOps.

  • Puppet Labs talks Docker and containerization

    Puppet Labs talks Docker and containerization

    Last week Puppet Labs released a new version of Puppet Enterprise that brought forward a number of new features, including those to Puppet Node manager that helps automate the provisioning of infrastructure from containers to bare metal, as well as a new AWS module that helps automate provisioning, configuration and management of AWS resources using Puppet. As a part of the release, Puppet announced it was officially supporting a Puppet module for Docker that has been kicking around Puppet Forge since the containerization tool went open source.  With 90,000 downloads behind it and many more customers clamoring for advice on how to better automate workflows in Puppet-controlled infrastructure while using Docker, the module had gained critical mass. staging-devopsy.kinsta.cloud took the announcement as an opportunity to catch up with Gareth Rushgrove, senior software engineer with Puppet and author of the Docker module, to discuss containerization and how Puppet is working to help customers take better advantage of container environments.

    What do you consider some of the biggest challenges when deploying containers in the real world? And how is Puppet Labs hoping to help customers get the most out of Docker?

    I think the first thing is really just…

     

    –THIS STORY HAS BEEN MOVED TO CONTAINER JOURNAL–

  • DevOps at REA Group

    DevOps at REA Group

    “DevOps is 100 years old, and probably invented by a British engineer in the 1920s,” according to Nigel Dalton, CIO at REA Group, the company behind realestate.com.au and other leading real estate sites in Australia, Hong Kong and Europe.

    He was referring to the work of Frank Woollard at Morris Motors in the UK. In 1925, Woollard produced a paper titled Some Notes on British Methods of Continuous Production in which he wrote “The ideal of continuous flow must be present from the design and raw material stages up to and even beyond the sales stage.” (This paper can be found in Bob Emiliani’s annotated reprint of Woollard’s Principles of Mass and Flow Production.)

    “There’s nothing new under the sun with DevOps — we’re doing the same thing [as Woollard],” said Dalton. “We’re reproducing practices that are 100 years old.”

    They might be even older, he said, pointing to research suggesting China’s Terracotta Warriors were made using flow manufacturing around 200BC.

    While the principles are old, “the cutting edge today is DevOps.”

    REA’s DevOps journey began around three years ago when the company’s applications and website covering commercial and residential sales, rentals and shared accommodation were being moved to a new Java-based platform. It was “an epic migration” involving a large team from REA and consultancy ThoughtWorks, and one that triggered consideration of how to do things even better.

    People like REA’s Trent Hornibrook (then infrastructure lead, but now delivery lead) realised greater changes were needed, Dalton said. “I doubt that bosses could tell people to do DevOps — they’d find a million reasons to avoid it. It’s a practitioner, grass-roots thing.”

    Hornibrook likened the situation that results from separate development and operations groups to working on a car production line and finding that a door doesn’t fit the body. Production grinds to a halt, but that could have been avoided with better collaboration further back in the process, so it’s largely about making the feedback cycle quicker.

    The idea of a monthly development cycle where operations signs off at the end of the month “couldn’t go on in a world where things were moving faster,” said Dalton.

    The company was still organised in functional groups: IT development, IT operations, marketing, sales, and so on. But as it moved to customer-segmented operations, these divisions were no longer appropriate.

    So REA reorganised into business units covering its commercial, residential and property developer customers. “We got rid of IT operations, and put operations people into the teams,” he said.

    The only centralised IT development workers are the global infrastructure and architecture team of around 12 people who build tools and measurement technology, manage the company’s use of Amazon Web Services, and provide consulting services. “They’re not high and mighty enterprise architects, they’re hands-on.”

    The approximately 180 developers are part of the delivery teams that focus on the entire lifecycle of their applications, Hornibrook explained. “We’ve driven the autonomy and accountability down to individual teams,” and this has resulted in high levels of staff engagement.

    Scaling IT is difficult, he observed, so it is necessary to provide that autonomy. While it does mean some work is duplicated, that’s a worthwhile trade-off for the increased throughput.

    Dalton agreed, pointing out that the real estate business is changing rapidly, and REA’s ability to match that speed makes the organisation more resilient.

    “The business benefits of adopting DevOps are significant,” said Dalton. The lean approach focuses on value, flow and waste, and DevOps improves flow and reduces waste. It is not logical to block flow by addressing operational issues at the end of a cycle — it’s much better to embed that function along the development process.

    Another factor that allows IT at REA to keep pace with the business is that “we don’t have vendor dependency.” Rather than being locked in to the development cycles, the company uses a lot of open source software. “The tooling around DevOps is incredible… I reckon we use 50 tools that I know about across the teams,” Dalton said.

    Similarly, REA employees are actively involved in Meetups, DevOps Days and other community events. In addition to gaining and sharing knowledge, this helps make REA an employer of choice, said Hornibrook.

    The introduction of DevOps does require attention to various organisational issues, including governance. For example, the idea of separation of duties as a defence against certain kinds of malpractice goes out the window. “It’s a good concept, but an old concept,” Dalton said, and one that can be largely replaced by peer checking. He suggested it was much easier to make ‘unauthorised’ changes to code 20 years ago when it was commonplace for developers to work independently on a routine or module, but greater peer involvement and teamwork has made a big difference

    “It’s all about outcomes,” he said. “We have controls.”

    The adoption of DevOps does mean “the guardians of compliance have to learn more skills,” Dalton said. Tools such as GitHub record the changes that are made, but auditors need to learn how to use them. “All the evidence is there, they just have to find it.”

    “Think about security at the beginning of the process and it’ll probably be better,” he added.

    And when it comes to the functionality and quality of the software developed, accountability is an important motivator: if a particular component breaks, then the people who caused the problem will be the ones that have to fix it.

    “DevOps is human behaviour and collaboration, yet it’s deeply technical,” said Dalton. REA’s biggest problem is finding people who will work collaboratively and take responsibility. Also — and how many times have we heard this about IT staff? — “Communication skills are really vital.”

    Another important attribute that Hornibrook looks for is malleability, because “change is so confronting.”

    “A focus on individuals within a work culture and mindset is a key element that prevents the adoption of DevOps,” he said. An important first step for someone in a role like his is to shepherd employees into a shared vision and purpose.

    That, suggested Dalton, is helped by the way REA does not have a highfalutin mission statement, just a simple raison d’être: ‘Our purpose is to empower people by making property simple, efficient and stress-free.’

    There’s also a benefit from one of the most basic Agile tools — cards on walls. This turns a binary ‘you versus me’ situation such as one person asking another whether a certain change has been made correctly into a ‘you and me versus the cards’ situation, and that’s a very different dynamic, according to Dalton.

    The deeper collaboration is spreading from within IT into other functions such as marketing and sales. Dalton calls this ‘product DevOps,’ and added “we can lead that if we get our own house in order.” It helps that REA has already adopted Agile principles across several functional areas, including the call centre and the legal team.

    “That’s how this organisation succeeds at pace and with flow,” he said. “Learn, learn, learn, with a relentless focus on the customer.”

    That customer focus addresses the question of whether REA is building the right products, Hornibrook pointed out. Dalton agreed, observing “with DevOps and Agile, we can make the wrong thing really fast, but that’s not helpful.”

  • 8 Signs of Docker Ecosystem Empire-Building

    8 Signs of Docker Ecosystem Empire-Building

    Docker’s meteoric rise on the strength of the continuous delivery movement’s thirst for containerization has been nothing short of remarkable. There’s perhaps no bigger sign of Docker’s uptake than in the build-up of its third-party ecosystem. The past year has seen partnerships galore from Docker and the biggest IT industry players,  plus notable support of the Docker ecosystem amongst key service providers. Here’s our take on some of the cross-industry relationships that will make the Docker ecosystem stronger.

    1. Google

    Google has had a big hand in helping to foster a collaborative Docker community, notably with the open source release of its Kubernetes container cluster manager. The project has gained tons of cross-industry support from IBM, Microsoft, Red Hat and more.  Google is further strengthening its ties in collaboration with Mirantis Partners with the reveal last month that Goog would work on a project with the OpenStack firm to  simplify the installation and management of Kubernetes applications on OpenStack.

    2. VMware

    Late last summer, VMware announced that it was working alongside Google, Pivotal and Docker to make it easier for enterprises to scale container-based applications on VMware infrastructure. As part of the deal, VMware agreed to collaborate on open source projects like libswarm, libcontainer and libchan, and to work with Docker to improve interoperability between Docker Hub, vCloud Air, vCenter Server and vCloud Automation Center.

    3. RedHat

    Just this month, Red Hat brought to fruition its plans to support Docker and other containerization technologies with the launch of its Red Hat Enterprise  Linux Atomic  Host operating system. Based on work done in the Project Atomic open source project, the OS is meant to offer a reliable platform for Docker, Kubernetes, Flannel and others for the enterprise market.

    4. Amazon

    For the past year Amazon has been bending over backwards to help customers more effectively leverage Docker on AWS infrastructure. Most notable was its big splash last November with the launch of its EC2 Container service (ECS), designed to simplify the management of Docker containers across a managed cluster of EC2 instances. It continues to add to that service—last month it provided updated enhancements to ECS that makes it able to use images stored in private docker repositories and to mount volumes in containers in ECS. 

    5. Rackspace

    Rackspace’s long-running relationship with Docker starts first as a user, but extended notably beyond that in June last year when it was working to contribute to the Libswarm project and had created a backend plug-in for Libswarm that would enable its users to launch Rackspace Cloud Servers directly from the Docker CLI. 

    6. IBM

    After a year full of big wins for the Docker ecosystem in 2014, it ended with a bang in November when IBM joined forces with the containerization upstart to integrate it into a range of applications for the enterprise market. As a part of the partnership, IBM launched IBM Containers, a Docker-based service delivered as a part of its Bluemix open cloud platform for application development. 

    7. Microsoft

    Microsoft has been incrementally upping the ante with its Docker relationship, starting in June 2014 when it added support for Docker  Microsoft added support for Docker in Microsoft Azure on Linux VMs. By October it had publicly committed to support Docker on future Windows Server releases, by adding resources to implement in-house tweaks to Windows Server and to support the open-source development of the Docker Engine for Windows Server. And in January Microsoft showed its commitment to the partnership with the release an Ubuntu image fully integrated with Docker and ready to deploy from the Microsoft Azure marketplace. 

    8. Puppet Labs               

    The most recent among Docker’s ecosystem wins, Puppet Labs this week pushed forward a new version of Puppet Enterprise  that includes a special module specifically for managing the Docker Platform and launching containers in Puppet-managed infrastructure.  The idea is to help users side-step configuration issues with the Docker daemon running containers.

  • Jez Humble Leads Next Round of Speakers Announced for DevOps Connect @ RSA Conference

    Jez Humble Leads Next Round of Speakers Announced for DevOps Connect @ RSA Conference

    The next round of speakers has been announced for the DevOps Connect: SecDevOps event at RSA Conference. Joining the previously announced group we are pleased to announce the following distinguished presenters added to the agenda:

    Jez Humble of Chef and renowned author
    Jessica Devita of Microsoft
    Nick Galbreath of Signal Sciences Corp and formally of Etsy
    Dan Cundiff of Target
    Chris Walsh of Signal
    Sarah Alhafidh of Intuit
    David Mortman of Dell
    Rich Mogull of Securosis

    Most of these people need no introduction to the Infosec and DevOps community. The exact schedule with titles of talks as well as the final wave of speakers will be released next week.

    Additionally, Gene Kim and Joshua Corman will be delivering the opening keynote titled: Rugged DevOps: Faster/Safer with Software Supply Chains

    It promises to be quite a day of DevOps and security that you don’t want to miss. The event is open and free to all badge holders of the RSA Conference. Unfortunately, there were only 600 pre-registrations allowed and we reached that level last week.  However, pre-registration does not guarantee a seat, RSA Conference will seat you on a first come, first serve basis. So come early even if you are not pre-registered.

    The event is all day on Monday April 20th. The event starts at 9am but you can arrive early. People may not stay for the full day, so again you should be able to attend even if you missed the pre-registration window.  We are just a few weeks away and hope to see you in San Francisco for RSA Conference!

  • IBM’s Watson sits at the crossroads between DevOps and Big Data

    IBM’s Watson sits at the crossroads between DevOps and Big Data

    While attending IBM InterConnect in late February I had an opportunity to sit in on a press conference. The focus of the press conference was primarily around IBM’s efforts related to hybrid cloud solutions, but the thing that caught my attention was a little tidbit mentioned almost in passing about an innovative way students at the University of Texas Austin had applied the power of the Watson supercomputer.

    Robert LeBlanc, senior VP of IBM Cloud, and a handful of other executives shared IBM’s vision for hybrid cloud and big data analytics with the media. The press conference ranged from data sprawl, to data visibility, to security and performance. The group talked about a focus on developers and the importance of open standards and more.

    Then there was the bit about Watson and the University of Texas. For those who may not know, Watson is a cognitive computing system. It is a supercomputer with an artificial intelligence component that enables is to analyze massive volumes of data, understand complex queries posed in natural language, and respond with evidence-based answers. It learns as it goes.

    Watson University Competition

    IBM has enlisted the support of companies and organizations around the world to help develop new applications for Watson and push the envelope of its capabilities. One of the programs that helps drive innovation with Watson is the Watson University Competition.

    Students participating in IBM’s Watson University Competition were directed to identify and solve an industry-specific challenge using Watson. Students had to work as a team to identify and input relevant data into Watson in order to train the supercomputer to answer questions related to the issue being solved. The students must then develop an app and supporting business plan targeting their chosen industry.

    The UT Austin team won the competition with an app called CallScout. The purpose of the app is to help Texas residents find information about social services and programs in their local area. Many Texas residents depend on state resources for housing, healthcare, transportation and other vital functions, but wading through government websites and other information is confusing and makes it difficult for residents to find the information they need. The CallScout app integratesl hours of service, route and map information and other relevant data, and it can automatically deliver push notifications when important details change.

    “This is more than a school project for us – it’s about creating a sustainable business that addresses one of the key challenges we all face as Texas residents,” said Bri Connelly, team leader and undergraduate Computer Science student at the University of Texas at Austin. “The opportunity to directly impact citizens of our home state was a huge driving force in our work.”

    Watson depends on DevOps

    Watson is a powerful platform for analyzing and understanding information. More than any technology or platform that has preceded it, though, Watson also depends on constant evolution. IBM has embraced DevOps principles for developing and maintaining Watson out of necessity. Watson simply wouldn’t be possible and wouldn’t be able to keep up with the pace of ingesting and adapting to information using legacy development models.

    The IBM Watson team manages the rapid pace of change using DevOps principles, which are an extension of Agile development methods. Carl Kraenzel, an IBM distinguished engineer and director of the IBM Watson managed services group, explained that effectively maintaining Watson means adopting continuous delivery and continuous availability. “If you don’t approach it the right way, change is a cost driver. It will add cost instead of adding value. DevOps helps us achieve continuous delivery, and DevOps helps us deliver continuous value.”

    IBM is a resilient company. It doesn’t have the same dominant role in the tech industry that it once had, but it didn’t just sulk off into the sunset. IBM has adapted and evolved. IBM InterConnect was an excellent demonstration of the innovation and vision driving IBM right now—positioning IBM to play a significant role in the new cloud, mobile, DevOps future. Watson, and the work done by the UT Austin team and other students are perfect examples of what’s possible when DevOps principles and cutting edge technology are applied to help resolve the issues that face mankind.

  • Adopt DevOps Practices Organically, But Don’t “DO DevOps” (or is DevOps bullshit?)

    Adopt DevOps Practices Organically, But Don’t “DO DevOps” (or is DevOps bullshit?)

    In a post on his blog , programmer Josh Johnson points out that “radical claims of great cultural shifts, especially in technology” are usually “bullshit”. “Over time technology changes, but true radicalism is rare. Most often, a reinvention or revisiting of past ideas forms the basis for such claims. This DevOps thing was no different,” says the post from Josh Johnson, Software Engineer at Adzerk.

    In 15 years as a technology journalist, I’ve heard vendors use labels and marketing speak to sell solutions. You can’t judge the efficacy of a solution by its label any more than you can “tell a book by its cover.” But is there something to these devops practices that we should take seriously? Should we make the effort to separate the wheat from the chaff, the faster, better software builds from the buzzwords and BS? I think so. And when I read Josh’s post, I came to believe that he thinks so, too. Josh shared his thoughts with me. Here are the fruits of that exchange.

    First, no one should be doing devops. It’s not an action, it’s not a title, it’s a blanket term for approaches that bridge the gap between traditional operations and development groups, says Johnson. Second, having devops teams is wrong. “Sectioning off a group of people and giving them special projects and expecting devops skills doesn’t fix the divide, it creates new divides,” says Johnson. This leaves other developers and ops people, not to mention management, out of that inner circle. “The value of devops is in the cross-functional aspects of bringing people together from different disciplines,” says Johnson. True devops should include everyone.

    A healthy, organic transition to devops practices should encourage people who specialize in operations or development to apply their specialties to the fullest while learning what the other side does. “If I’m the security expert,” says Johnson, “I’m going to monitor CVE feeds and recommend policy and practice. On a cross-functional team, I will also perform code reviews, participate directly as a peer in planning, and help the QA specialist by turning them on to fuzz testing. They’ll teach me how to use Selenium. I’m still the security expert.” In this scenario, the security expert grows and benefits and so does everyone whose work he touches.

    Hurdles

    The company will make compromises. The enterprise is asking a lot of its people and will have to pay to get it. The turnover in human resources can slow change to a crawl. The organization will probably have to outsource at least some tools and talents. “You may have to use GitHub instead of hosting your own git server,” says Johnson.

    The more the devops metamorphosis progresses, the more the organization can lose central control of critical components. All things being equal, the bigger the enterprise, the harder it will be to let go. Initial costs and security concerns when getting started, together with outsourcing, can drive project scope through the roof. And that’s not the worst of it.

    “You might lose some great people. There are some people who really need to focus exclusively on their specialty. There are managers who don’t thrive outside of silos. There are people who will not be able to rise to the occasion and work well with their new teammates,” says Johnson.

    Don’t Force It

    To achieve a thriving instantiation of devops while maintaining your sanity, you have to guide everyone to simultaneously want these practices. Start by poking holes in silos and letting members of different teams peek through. “Take a team of bright, collaborative people, give them a goal (say, reduce downtime in deployments by half) and empower them to make it happen, and it will happen. DevOps will magically spring forth,” says Johnson.

    This organic approach is far afield of simply adding a devops team in hopes that it will save money by reducing staff. “Four DevOps engineers are not directly equivalent to two systems engineers and two software engineers,” says Johnson. If that’s the case, it’s worse yet to believe that you can replace four specialists with three experimental devops positions and maintain quality output at a savings of one FTE. Instead of saving money, this move may increase costs due to compressed time to burn out, expensive errors, and an enveloping drop in moral. “That will blow up in your face,” says Johnson.