Category: Features

  • Security and DevOps: the horses are finally here

    Security and DevOps: the horses are finally here

    It doesn’t seem like it was so long ago when it was actually difficult to find enterprises and experts who could speak – from experience – about having successfully managed security in a DevOps environment. Sure, they existed, but they were primarily the so-called “unicorns:” web-based enterprises that had little of the legacy infrastructure in place that also needed to be secured. Enterprises such as Netflix, Etsy, Google, Amazon, and others for who the cloud and virtualization management and DevOps practices are as natural as water.

    Fortunately, we’ve now experienced a year where stories about traditional enterprises having successfully made the DevOps leap are commonplace, from Macy’s and Target and others at the DevOps Enterprise Summit, while Nationwide and many others at IBM InterConnect.

    Like those conferences above, this year the annual RSA Conference (the information security industry’s biggest show), and some of the approximate satellite events this week, will have many sessions relating to DevOps and security. Our own DevOps Connect: SecOps Edition, being held Monday at the Moscone Center, is a daylong event highlighting the intersection of DevOps and information security.

    At DevOps Connect: SecOps Edition there are a number of must see sessions, for me, including David Mortman’s DevOps Myths Versus Real World Realities, Julie Tsai’s Windfall Wins: DevOps Empowers Agile Security and Compliance, and Jez Humble on Continuous Delivery.

    Also, throughout the week there are many DevOps and security sessions throughout the week in application security related tracks. There will be a lot of interesting news and developments coming from those sessions throughout the week.

    Here are some, for those interested in learning more about DevOps and security, that look very worthwhile:

    Continuous Security: 5 Ways DevOps Improves Security

    Joshua Corman, Chief Technical Officer, Sonatype and David Mortman, Chief Security Architect, Dell

    DevOps is upon you and no longer just the provenance of start-ups. Josh and David will discuss how things have changed and five ways security gets better as a result of other teams doing DevOps.

    Enterprise Cloud Security via DevSecOps

    Scott Kennedy, Chief Security Scientist, Intuit; Shannon Lietz, Sr. Manager, DevSecOps, Intuit

    Securing innovation at scale in a cloud environment can be quite challenging. The goal of our talk is to share the lessons we learned about operating under the DevSecOps model.

    How to Avoid the Top 10 Software Security Flaws

    Gary McGraw, Chief Technical Officer, Cigital

    DevOps and automation tools are changing both the breadth and speed at which risk propagates. This session will cover both how to monitor and respond to them without alienating your DevOps team.

     Is DevOps Breaking Your Company?

    Elizabeth Lawler, Chief Executive Officer / Founder, Conjur, Inc.

    DevOps and automation tools are changing both the breadth and speed at which risk propagates. This session will cover both how to monitor and respond to them without alienating your DevOps team.

      Containers vs. VMs for Secure Cloud Applications

    App developers and PaaS platforms are adopting containers to simplify app packaging, deployment and orchestration. But there has been no pause for thought about security and compliance.

    Participants:

    Simon Crosby – Chief Technical Officer, Bromium Inc

    Christofer Hoff – Vice President and Security Chief Technology Officer, Juniper Networks

    Mark Russinovich – Chief Technology Officer, Azure, Microsoft

    Scott Johnston – Senior Vice President Product, Docker

    How Security Can Be the Next Force Multiplier in DevOps

    Andrew Storms Vice President, Security Services, New Context

    DevOps is the hottest moving target when it comes to software development methodologies. Many people fear that this fast paced, barrier breaking movement will leave information security best practices.

    After the week is over, a great deal more security professionals in the industry should have a stronger grip on how to better incorporate security into DevOps practices and improve enterprise IT outcomes while reducing risk.

  • Swapping Engines In Flight: Transforming Brownfield Enterprise Applications

    Swapping Engines In Flight: Transforming Brownfield Enterprise Applications

    As DevOps thinking becomes more mainstream, enterprises will need to incorporate new ways of developing and delivering applications into their standard IT processes. Enterprises that are often complex and constrained by existing legacy infrastructure, organizations and processes must consider how and when to transition brownfield enterprise applications to an agile approach. With production applications on legacy infrastructure, how do you think about “changing the engine on a flying plane”?

    DevOps guru and practitioner Rob Berger joined me on a recent devopsy.kinsta.cloud webinar to deep dive on these topics.

    What Is Brownfield?

    The EPA defines brownfields as “real property, the expansion, redevelopment, or reuse of which may be complicated by the presence or potential presence of a hazardous substance, pollutant, or contaminant.”

    It’s humorous to think about our enterprise legacy apps being toxic dump sites and might feel that way at various points in our efforts to transform them, but in our world, brownfield simply refers to an existing application or service that is already in production. It was likely built using previous generation tools, serving mainframe or client server architectures, any time from decade(s) to a few years ago.

    While “legacy” conjures images of a sleepy, backwater enterprise, brownfield is actually ubiquitous. Any company with existing computer based services has brownfield transitions to figure out because you can’t just throw away what’s in production today. Even when doing startups, it’s amazing how fast legacy can happen.

    So how do you think about continuing to serve customers with an existing brownfield application in production, while transforming it into a modern web-scale application?

    A Note On DevOps

    Remember that first and foremost, DevOps is a process and journey. Different organizations are going to be at different stages at being DevOps.

    Rob referred to Conway’s law, which states that “organizations which design systems… are constrained to produce designs which are copies of the communication structures of these organizations.” The takeaway is, make sure that the organization is compatible with what you’re trying to achieve. It is so critical that you break down silos and improve communications between all parties involved, even more so than the technology.

    So, What Apps?

    Enterprise applications largely fall into three categories. Many are going to be pre-existing custom applications, the kind that are wrapped around core organizational structure or business functionality. They are both the most challenging applications to transform, as well as the highest reward to figure out. You want to figure out how to offer things like mobile or web apps that leverage the existing app to slowly transform to the new way of doing things.

    Related to the pre-existing applications are packaged applications from vendors because they can be as much wrapped up in the way you do business as the custom apps. Some vendors can support the migration, but more often you will have to identify the most critical new business functionality and move that to the new DevOps style.

    In some ways, the easiest to deal with are new applications. They are greenfield opportunities to start from fresh with a new DevOps style team, with continuous integration, test driven development, and an organizational structure that reflects that.

    Let’s say that you have a monolithic existing application that was written 8-10 years ago using standard open source technology C++ or Java in a waterfall model by a large system integrator. The market demands that the service modernize beyond the incremental changes that occur in the long cycle releases. What are the steps that you would go through to transform this app to the DevOps world?

    Step One – Minimum Viable Product

    You don’t want to create a complete replacement of your legacy application, and certainly don’t want to disrupt your existing business. But you do want to evolve it so that you can meet the needs of your more modern demands.

    At the organization level, identify the most critical thing that you must deliver. What is the highest priority demand and what gives you the most bang for your buck? What is the “minimal viable product” for this new thing you want to do? Figure out the smallest scope to transform that will have the biggest impact. A easy example might be to add a mobile interface to your existing system because it just maps the user interface with the same business logic in the back end.

    Step Two – Create The (Right) Team

    You need a small team that has a mix of the right people to deliver this minimum viable project. It requires representation across functional groups

    • Business group or product manager,
    • Key developers,
    • IT operations who will automate the creation of the service (not just jockey a server)

    Look at your current organization and architecture to identify the people that can adapt to the new way of doing things. Finding the right people who believe in the new way of doing things is critical to building responsive apps, per Conway’s law. Understand the internal politics and how to mitigate interpersonal dynamics. Don’t get bogged down in the past, but you need functioning teams that collaborate well to not disrupt your business.

    Step Three – Build REST APIs

    Your new application will built as self contained services for manageability and scalability, exposed through REST APIs. Identify what services you need from the legacy system, and create REST API around the legacy system that can expose the services from the legacy system to the new system. You will need people that understand both the legacy and new system to make this work.

    One of the biggest variables will be how to most gently and elegantly wrap a REST interface around the legacy app. You want the new system to just talk to REST, and it doesn’t need to know anything about legacy app.

    Step Four – Design The New Service

    Use modern tools. Microservices should be at foundation of whatever you do. Figure out the components that can be considered independent and have its own lifecycle, tied together by REST or JSON interfaces. By identifying the minimum viable product, you should be working in 2-3 week cycles so that you can see the results fairly quickly.

    Why Microservices

    Your new apps should be loosely coupled architectures that are called microservices. Microservices tend to use RESTful APIs as the primary way that they communicate.

    Think of each microservice as a functional block, like in functional programming where there are specific inputs and outputs, and the side effects should be non existent or very controlled. This allows you to know precisely to know what’s going on inside each box. Interoperation is explicit through REST or streaming interfaces. In both cases you can have schema repository that becomes the definition of how microservices talk with each other.

    Automate Everything

    Every time a software developer commits code into a Git repository, it should automatically be deployed into a QA or staging environment. Lay that rule down from the beginning. If you’re building individual servers by hand, that’s a good indication that you’re going to have problems. The goal is for everything to be scripted or your infrastructure represented as code, using configuration automation system like Chef and Puppet at the core of how you are deploying services.

    You almost want to treat servers like immutable things that you throw away when you want to update it. The only way to do that is to automate, which leads to the application side concept of continuous delivery or continuous integration. Get to policy driven management, where policies are embedded in code.

    Remember, You’re Not Replacing Your Legacy

    This is a journey and you’re just starting on the evolutionary path for independence.

    Keep in mind that you will likely have both the old and new running in parallel for a short time. You’ll want to figure out how to use your legacy system as a back end, with a decoupled front end that can then evolve independently to the back end. And leading to the next point, remember that your team running the new components and the legacy app will have to collaborate closely as you transform the enterprise.

    About the Author / Varma Kunaparaju

    YaCNNVuUVarma Kunaparaju is CTO at Vistara and a seasoned technologist with over 20 years of experience leading engineering teams to deliver enterprise software. Reach him on twitter: @varma1

     

     

     

  • Get started with Docker with video training course from O’Reilly

    Get started with Docker with video training course from O’Reilly

    Container platforms seem to be the fuel driving the next wave of app development. Docker didn’t invent the concept, but Docker’s meteoric rise made container technology mainstream. Don’t worry if you’re still not quite sure what Docker is or how to use it—O’Reilly Media has you covered with its Introduction to Docker video training course.

    Catch the Docker wave

    If you aren’t already on the Docker bandwagon you’re a little behind the curve at this point. Docker breaks down barriers and enables developers to deploy apps more effectively and efficiently with less effort than traditional application development and deployment technologies. Docker lets you build an app in any language, and run it on any platform that supports Docker containers.

    At this point there aren’t many platforms that don’t support Docker. It has quickly become the de facto standard for container technologies. Microsoft has its own Windows Server Containers and recently introduced more secure Hyper-V Containers, but it also partnered with Docker to bring Docker containers to Azure, and it is working with Docker to integrate native support for Docker in the next release of Windows Server.

    In a nutshell, Docker is here to stay. If you’re developing and deploying apps its imperative that you know what Docker is and how to use it or you may get left in the dust.

    Learning Docker

    The Docker video training is presented by Andrew Tork Baker. Baker is an independent consultant based in Washington, DC and is a respected resource when it comes to Docker containers. He also goes by the handle “atbaker” and wrote spin-docker—a lightweight open-source Platform-as-a-Service powered by Docker and Flask.

    The entire training session is one hour and 46 minutes and costs $60 to download or stream from O’Reilly. You can watch the first three segments—about 10 minutes worth of content—for free to get a feel for the scope and quality before deciding whether or not to purchase the training.

    The video quality is adequate. Baker speaks a tad fast in parts—probably an effort to prevent the training from running too long or becoming boring. Overall, though, he speaks clearly and presents the materials in a way most people should be able to comprehend. That said, it’s an introductory course so don’t go into this planning on being a Docker guru in a couple hours.

    Baker covers a range of topics in the course. He starts from an overview of what Docker is (and isn’t) and how to set up your Docker development environment (both of those segments are part of the free preview), and then moves on to basic Docker concepts, working with containers, and finally to more advanced areas like Dockerfiles and how to deploy a Docker app to the cloud. The training concludes with recommendations for additional resources to continue diving deeper and learning more about Docker.

    There are only a handful of reviews for the Introduction to Docker video training course so far, but they’re all positive. So far it has an average rating of 4.5 out of 5 stars, and all of the reviewers would recommend the training to a friend. The reviews do stress that it’s an introductory course, though—just enough to give you a basic understanding.

    If you’re new to Docker or container technologies and want to get a grasp on the basics this is probably a good investment of $60 and two hours of your life.

  • DevOps Connect: Rugged DevOps @ InfoSecurity Europe

    DevOps Connect: Rugged DevOps @ InfoSecurity Europe

    Following up on the tremendous demand we have seen for DevOps Connect @RSA Conference, we are taking this concept across the pond to Europe’s largest InfoSecurity event. DevOps Connect: Rugged DevOps @ InfoSecurity Europe will be on June 4th, 2015 at the Olympia in London. Partnering with the InfoSecurity Group and Reed Exhibitions, DevOps Connect will feature a full day of DevOps sessions, followed by a cocktail reception.

    We will be announcing some exciting keynote speakers shortly, but there are plenty of speaker slots still available. Here is some information on the event for attendees, speakers and sponsors:

    Attendees: All registered attendees of InfoSecurity Europe are eligible to attend DevOps Connect.  Even better registration for InfoSecurity Europe is free! So anyone can register for the event and come to DevOps Connect. Here is the link to register. While anyone can register and attend, the theater at the Olympia where the event will take place has limited seating. So our advice is register quickly and come early.

    Speakers: We are issuing a formal call for speakers which is very similar to the CFS that we used for the RSA event (actually it is the same form).  Here is the link to submit to speak. Please be sure to read the instructions in the Details section. It really explains what we are looking for in speakers for this event.  We invite anyone who would like to speak to submit. The deadline for speaking submissions is May 4th. So don’t delay, submit early!

    Sponsors: We have a full slate of sponsorship packages available for this event. Sponsor packages include sponsoring/exhibiting at both InfoSecurity Europe, as well as the DevOps Connect event. If your company is already sponsoring or exhibiting at InfoSecurity Europe, we have packages that allow you to leverage your existing investment. For information on sponsoring DevOps Connect and InfoSecurity Europe contact sponsor@devops.com. Sponsoring DevOps Connect is a great way to reach both of these communities, as well as help bring better awareness to both communities.

    The idea of DevOps Connect: Rugged DevOps is to bring together the DevOps community and the InfoSec community. London has one of the most vibrant DevOps community in the world (it is the single biggest city for devopsy.kinsta.cloud visitors) and InfoSecurity is the largest InfoSec event in Europe with over 12,000 attendees.  So this is a perfect venue to bring together these two great communities. We invite members of both the DevOps and the InfoSec world to participate in this.

    Stay tuned for more news and information regarding DevOps Connect: Rugged DevOps over the next days and weeks. Stay tuned.

  • Mixcloud Makeover: Faster Development, More Confidence

    Mixcloud Makeover: Faster Development, More Confidence

    “Mixcloud provides audio hosting and distribution for millions of podcasters and DJs,” says Matthew Clayton, CTO & Co-Founder, Mixcloud. Mixcloud’s developers program the site in python (Django) and javascript, and develop their native mobile apps in Java and Objective-C. The Mixcloud team grew its mammoth Django monolith application over a five year period. Mixcloud’s primary server infrastructure supports this application, which makes up most of its code base.

    The Legacy Development Workflow & Goals For The Future

    The Mixcloud team used to code its application on a branch, deploy the branch, check for stability, merge it into the master branch and redeploy it. “We used to branch the code on git, then push this to github so that all the team could see the branches developing in parallel,” says Clayton. To check code stability, the Mixcloud team used to simply watch to see whether the site crashed on a single server. “We originally didn’t have any tests, so this was really the only way we could see whether there was a problem,” says Clayton.

    The old overall development methodology also produced challenges every time Mixcloud hired new developers. “Adding developers who didn’t understand the entire stack massively increased the likelihood of bugs and the risk of downtime,” says Clayton.

    When Mixcloud went looking for a DevOps / continuous delivery approach, it had in mind to increase the quality of the code its developers produced and to increase the team’s confidence in the code they shipped to production while overall having faster development.

    New Workflow, Bumps In The Road

    Today, Mixcloud hosts and reviews its code using github.com. The company uses Slack for internal communications. The team uses getsentry.com for exception handling and Asana for product feature and bug tracking. “We use Codeship for running Linting (python/JS/Templates), JS unit tests, Python tests, Selenium integration tests, and database integration tests,” says Clayton.

    Python/JS/Templates enable code linting by leveraging tools such as pylint, jslint, and Django-extensions to perform static analysis and to lint the appropriate code.

    But the path to DevOps enlightenment and improvements is never ending. It took some time for Clayton and his team to understand how all the working components affect each other as they integrate together. “We still have not included database migrations in our release process. This is still a manual process,” says Clayton. Mixcloud will eventually add this too to its list of automated endeavors.

    Navigating The DevOps / Continuous Delivery Maze

    At the very start of a round trip through the new development process, Mixcloud developers will open up a pull request on github.com and assign it to another team member. This action automatically sets a complete build in motion and deploys a staging infrastructure. “The assigned developer will now review the pull request using github, and also the running code. Once this review process is complete, the branch merges with the master,” says Clayton.

    This will next set off a deployment in production. When the team is ready, they will run a single command to activate the new code for each and every user. “The whole test and deploy process now takes about three minutes. This enables a rapid iteration,” says Clayton.

    Benefits & Surprises

    Two of the biggest benefits for Mixcloud were adding code linting and pull request reviews. “These helped the team become more aware of changes across the entire code base, and eradicated entire classes of bugs for what is essentially a fixed, one-off engineering cost,” says Clayton.

    When compared with the legacy development methodology that could introduce new bugs every time a new developer came on board, the Mixcloud team now only introduces bugs of a magnitude that could create website outages and downtime in the rarest of cases.

    But the major unpredicted upside was how the automation and the reduction in manual testing added to the productivity and development speed. “Surprisingly, there have been massive improvements to interaction speed among team members. We are seeing productivity and developer happiness that are significantly better than before the change,” says Clayton. The ability for the development process to refactor huge amounts of code with confidence has also made great strides forward.

  • Hyper-V Containers combine virtualization with containerization

    Hyper-V Containers combine virtualization with containerization

    Containers are all the rage these days. You’re just not cool if you’re not using Docker or some other container technology to build and deploy your IT infrastructure. Traditional containers, however, lack sufficient security for some industries and companies, so Microsoft developed Hyper-V Containers.

    Container platforms like Docker and Rocket have significant momentum and have quickly become established as a de facto way of developing and deploying applications. Microsoft already entered into an arrangement to bring native Docker container support to Windows Server, but now it is going a step farther by creating Hyper-V Containers that combine the agility of containers with the security of virtualization.

    Hyper-V Containers ensure that code running in one container object remains completely isolated. The Hyper-V Container object cannot impact other container objects or the host operating system, or vice versa, because it is a separate virtualized container. Mike Neil, general manager of Windows Server for Microsoft, explained in a blog post, “Leveraging our deep virtualization experience, Microsoft will now offer containers with a new level of isolation previously reserved only for fully dedicated physical or virtual machines, while maintaining an agile and efficient experience with full Docker cross-platform integration.”

    IT admins will appreciate the fact that Hyper-V Containers can be created and deployed using the same development and management tools used for traditional Windows Server Containers and that they integrate with Docker for cross-platform deployment. Neil points out that applications developed as Windows Server Containers can easily be deployed as Hyper-V Containers without any modification—enabling organizations to take existing containerized apps and re-deploy them in a more secure manner.

    It seems like security is always an afterthought to any new technology concept, and containers is no exception. It started out as a good idea that caught fire, but it wasn’t until it hit critical mass and achieved mainstream adoption that security became a factor. As larger companies, or organizations in highly-regulated industries look at jumping on the container bandwagon, though, security becomes a mandatory component.

    Virtualization has been used in hosted environments for years as a means of isolating different systems running on the same physical hardware or network. Microsoft’s Hyper-V Containers take those same principles and apply them at the container app level so that security-conscious organizations can have some peace of mind and remain compliant with security mandates as they embrace containerization.

    Microsoft’s strategy of integrating Windows Server Containers and native Docker support in Windows Server and Azure was a big step in the right direction. Adding the security of Hyper-V Containers is brilliant. Microsoft is doing an excellent job of pivoting its business model and not just embracing cloud and DevOps technologies, but raising the bar and taking the lead.

    As a side note Microsoft also announced Nano Server—a new minimal footprint implementation of Windows Server optimized for cloud hosting and container technologies. The Nano Server installation includes the bare minimum components necessary. Microsoft claims the result is smaller server images, faster deployment times, decreased network bandwidth consumption, and reduced administrative overhead. In other words a Nano Server installation of Windows Server will just do what it’s supposed to do with minimal interaction or oversight so IT personnel can focus on more important things like the Hyper-V Container apps running on it.

  • The Return of Workflows

    The Return of Workflows

    Recently workflows have emerged as a fundamental part of the operational wiring at companies as diverse as AWS, Facebook, HP, LinkedIn, Spotify, and Pinterest, which just open sourced Pinball. We’ve witnessed a spike of interest in workflow-based automation, and a few interesting implementations coming to the open-source world in just the last year or two: Mistral and TaskFlow from OpenStack ecosystem, Score from HP, Azkaban from LinkedIn, Luigi from Spotify, and dray.it by CenturyLink for the Docker ecosystem, to name a few.

    Workflows are used to orchestrate operations in infrastructure and applications, automate complex CI/CD processes, coordinate map/reduce jobs, and handle jobs to containers.

    It is not surprising that when it comes to higher level automation and orchestration, workflows are widely used. To quote the Pinterest blog: “In realistic settings it’s not uncommon to encounter a workflow composed of hundreds of nodes. Building, running and maintaining workflows of that complexity requires specialized tools. A Bash script won’t do.” Workflows are superior to scripts in concept and in practicality.

    (more…)

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