Tag: serverless computing

  • Stackery Smooths AWS Serverless Integration for DevOps

    Stackery Smooths AWS Serverless Integration for DevOps

    Stackery today announced a plug-in capability that will allow developers to build and debug code destined to run on the Lambda serverless computing service provided by Amazon Web Services (AWS) from within an integrated development environment (IDE) running on a local machine.

    Company CTO Chase Douglas said the latest Stackery tool can be dropped into any IDE, either via a Stackery VS Code Serverless Tools Plug-In that automates installation or a manual installation process, regardless of the programming language being employed. The goal is to make it easier for DevOps teams to construct workflows that include AWS serverless computing frameworks, which now are expanding rapidly, he said. In total, the Stackery tools can invoke any one of 86 AWS CloudFormation-compatible resources.

    Stackery provides a set of visual tools that make it easier to write functions for the AWS Lambda service without having to know how to create YAML files to manipulate infrastructure as code. This latest offering extends that capability to local environments, which will allow DevOps teams to work offline on their laptops and make changes without having to make every change on the AWS cloud over an internet connection. This capability does not require customers to set up a Stackery account to use it.

    Right now, Stackery is squarely focused on providing those tools for AWS environments, but Thomas said eventually those tools will be extended to other serverless computing environments.

    The goal is to provide DevOps teams with tools that make all serverless computing frameworks more accessible to both developers and IT operations teams, Douglas said.

    Serverless computing frameworks are gaining in popularity because they make it easier for developers to invoke additional IT infrastructure resources to kick off, for example, an analytics module whenever a certain event occurs within their application. That capability reduces the amount of code developers need to include in their core applications. Serverless computing frameworks are usually employed to run stateless processes for a very short amount of time, while containers and virtual machines continue to be relied on for running longer running applications. But for DevOps, that creates another layer of abstraction to include within the context of a larger continuous integration/continuous deployment workflow.

    Most organizations are already struggling with mastering the workflows they employ to manage the building and deployment of applications using containers and virtual machines, so any new abstraction layer of compute resources need to incorporate within the workflows easily if the providers of that service hope to achieve mainstream adoption among DevOps practitioners. Long-term, of course, the expectation is all these processes will be completely automated, which means developers only will have to ever worry about writing business logic.

    In the meantime, it’s likely to be a while before DevOps shops are invoking multiple serverless computing frameworks running on different clouds, much less automating them on end to end. That day, however, may not be as far off as people today might assume.

    — Mike Vizard

  • ASF Moves OpenWhisk Serverless Computing Forward

    ASF Moves OpenWhisk Serverless Computing Forward

    The Apache Software Foundation (ASF) announced today that the OpenWhisk serverless computing framework has now become a high-level open source project.

    Matt Rutkowski, CTO for serverless technologies and advocacy for IBM, said with this announcement, organizations looking to implement an open source serverless computing framework on-premises or in a public cloud now can have confidence the OpenWhisk project is sustainable beyond the handful of vendors, including IBM, that launched it.

    IT organizations of all sizes are embracing serverless computing frameworks as a way to invoke application programming interfaces (APIs) to make additional compute resources available on-demand based on an event. For example, rather than having to embed a lot of additional analytics code within their application, developers alternatively might invoke a serverless computing framework such as OpenWhisk to run analytics whenever necessary.

    The most widely used serverless computing framework today is the Lambda service from Amazon Web Services (AWS). However, rival cloud service providers have been embracing various open source alternatives to provide similar capabilities. At the same time, some internal IT operations teams are deploying serverless computing frameworks to provide similar capabilities within an internal IT environment.

    Regardless of the approach, Rutkowski said hooks to serverless computing frameworks soon will become ubiquitous hooks within continuous integration/continuous deployment environments. In fact, DevOps environments are likely to expose multiple hooks to different serverless computing frameworks as cloud computing becomes more hybrid, he noted. Plugging in multiple serverless computing frameworks should be relatively trivial because the difference in application programming interface (API) parameters between different serverless computing frameworks is minimal, he added.

    While interest in serverless computing has been running high, deciding which open source serverless computing framework to embrace has been something of a challenge. There are at least a half-dozen active serverless computing frameworks, with new ones being added regularly while other projects fade away. The Cloud Native Computing Foundation (CNCF) has made a point of not endorsing any one serverless computing framework in the expectation that many will be adopted for various use cases. Instead, the CNCF has thrown its weight behind a Knative project that provides the middleware required to integrate Kubernetes clusters with multiple serverless computing frameworks.

    Those serverless computing frameworks have already had a profound impact on containerized applications. The first generation of containerized applications was largely stateless. Now stateless functions increasingly are being processed via a serverless computing framework, while stateful applications based on containers that tend to run longer are just now starting to be deployed in production environments.

    Of course, the one fact many IT organizations fail to appreciate is that serverless computing frameworks are built using containers. A serverless computing framework is really a higher-level abstraction of a container platform. The challenge organizations will face now is teaching developers when to rely on a more traditional container platform versus invoking a serverless computing framework to run a child process, for example.

    Whatever path those developers choose, the one thing that is for certain is existing DevOps processes will need to be adjusted accordingly.

    — Mike Vizard

  • How Serverless Is Impacting the IT Landscape

    How Serverless Is Impacting the IT Landscape

    Although most users will never realize it, with every digital data entry and exchange servers are consuming substantial quantities of energy to file, store and sustain that data’s availability.

    While the average consumer or office worker doesn’t consider the economic or environmental impact they have, IT and C-Suite teams are awakening to the problem and the awareness among energy concerns, legislators and thought leaders is growing. From the expanding troves of transactional data for AI to each video streamed on a smartphone or to a social media platform, hyperconnected companies are hungry to collect, understand, feed and leverage data on our digital habits. In today’s infrastructure models, data centers continuously burn through processing power to be ever-ready to those workloads—even when demand falls during regular off-peak periods.

    That’s one of the two real pushes behind the shift from legacy to new serverless infrastructures: waste, both environmental and economic.

    The world is waking up to the realization that the digital economy is consuming disproportionate levels of energy, putting new pressures on their organizations, their region’s energy infrastructures and, ultimately, on the planet.

    A recent report from Climate Change News predicts billions of internet-connected devices could produce 3.5% of global emissions within 10 years and the communications industry could use 20% of all the world’s electricity by 2025. In fact, data from statistics portal Statista notes the energy consumption of Facebook usage alone amounted to about 2.46TW hours in 2017, compared to 532GW hours in 2011.

    In the U.S. alone, data centers consume an astounding 90 billion kWh of electricity per year, the approximate annual output of 34 (500MW) coal-burning power plants. The data center consumption costs are baked in—organizations pay for always-on computing power to meet peak need regardless of how demand may fluctuate.

    The Promise and Potential of Serverless

    Cutting Energy Consumption: Serverless compute technology such as Amazon’s AWS Lambda or Microsoft’s Azure Functions are native cloud architectures designed to decrease consumption and increase agility and innovation.

    It provides a more efficient function-as-a-service (FaaS) consumption model that enables organizations to pay for what they use, rather than constant peak demand charges.

    Some of the economic impacts of serverless are obvious: Organizations that host their own servers have reconciled themselves to paying for those servers running at full power while sitting idle for much of the time. It’s like keeping your car constantly running, regardless of whether you’re going anywhere.

    In contrast, serverless not only promises far greater energy efficiency from the macro-infrastructure perspective, it also is event-driven. Organizations pay by the computing power consumed, so their costs reflect their actual server usage rather than paying for always-on capacity.

    The Shift Is On, From Managing Infrastructures to Solving Problems

    Reduced energy consumption and cost efficiencies are important for organizations and the planet. Two other major promises serverless offers are the ability to let organizations focus on creating applications and services without chaining them to infrastructure and innovation opportunities.

    Organizations shift the focus of their IT resources away from infrastructure maintenance—the provisioning, patching, operating system maintenance, managing runtimes and capacity planning overhead—to solving business problems. This means the focus of the organization’s IT resources can shift from managing infrastructure maintenance burdens to doing what IT was always meant to do: solve actual business problems.

    But there’s another aspect to serverless that’s even more exciting.

    Unlocking ‘Vendor Lock’ and Unleashing Innovation

    Every great technology breakthrough inevitably tears through old barriers and accelerates innovation. Serverless is no different.

    Furnace is a good example. It’s a new open source, serverless, streaming data processing platform for building big data solutions that are cloud platform and language-agnostic.

    It supports the use of applications that run natively in AWS Lambda, Microsoft Azure and Google Cloud, passporting data between platforms. Using coding languages including JavaScript, Node, Python and Golang, a growing community of developers are creating constructs to connect cloud-based applications.

    Some of the most urgently needed application construct types we’re likely to see in the near term will be for extracting and anonymizing old proprietary data for GDPR compliance, and for honeypot data collection and manipulation, with Elasticsearch and Redshift. Other application foundational on-ramps are in development.

    According to Danny Waite, CTO for the Furnace Ignite organization, the Serverless Furnace source platform was architected to allow deployment and data traversal into and across various cloud, on-premises and hybrid environments, putting the underlying efficiencies of serverless to work on practical applications.

    The application development platform is optimized to ingest massive volumes of data from different sources and in various formats. The Furnace open source community is soliciting feedback and community developers are working on various projects, with plans for constructs to harness and tap into the massive stores of now-untouched IoT data, among other sources.

    Greener, Cleaner, Streamlined Computing

    Serverless is a driver for ecologically greener, operationally cleaner and innovation-driving new computing. Its reduced data-center energy consumption, pay-per-use event-driven model, openness to innovation and seemingly unique ability to help align historical data with new regulatory requirements are all arguments for a shift in thinking and embrace of serverless. The improved economics are another compelling reason, though likely not a primary one for data-driven organizations.

    Serverless communities such as Furnace Ignite are emerging with tools and techniques for adoption. The Furnace application development platform has been architected in a way that allows it to be deployed into various infrastructures, such as cloud, on-premises or within hybrid environments, with the ability to ingest huge volumes of data from different sources, in various formats, so developers can take that data and make it useable. The whole process can be done with speed and agility and removes all the nuances normally associated with working with streaming data.

    Serverless platforms such as Furnace will continue to be developed to drive DevOps and meet the needs of the opensource community.

    — John Blamire

  • CloudBees Further Extends Jenkins CI/CD Reach

    CloudBees Further Extends Jenkins CI/CD Reach

    CloudBees announced it is expanding the scope and reach of its Jenkins open source continuous integration/continuous development (CI/CD) platform into the realms of compliance and serverless computing frameworks.

    Announced at the DevOps World | Jenkins World conference in Nice, France, a new plugin for Jenkins adds support for the AWS Serverless Application Model (SAM) defined by Amazon Web Services (AWS). That model spans AWS Lambda functions, application programming interfaces and Amazon DynamoDB tables and is natively supported by AWS CloudFormation. The AWS SAM plugin supports both classic FreeStyle jobs and Jenkins Pipeline to make it possible to read and deploy serverless applications.

    In effect, CloudBees is making it possible to treat AWS Lambda as a natural extension of any CI/CD pipeline. Longer term, serverless computing frameworks will play a larger role in the cloud-native instance of CloudBees as well.

    In the meantime, CloudBees is also extending its CI/CD platform to address compliance issues that arise from identity management. CloudBees Core is now integrated with the LDAP-based directory Google makes available within its Cloud Identity service. This capability makes it possible to centralize user management policies by using the same Google Cloud Identity or G Suite credentials to connect to CloudBees Core.

    Christina Noren, chief product officer for CloudBees, noted governance and compliance are becoming much bigger issues within best DevOps practices as more responsibility for security continues to shift left toward developers.

    The CloudBees community continues to grow, even as the number of CI/CD rivals continues to expand. At the conference, CloudBees executives revealed the Jenkins community has grown 24 percent in the period Sept. 30, 2017, to September 30, 2018, reaching 192,623 active installations. That number only applies to installations that permit usage information to be transmitted to the Jenkins project, so this number is not representative of the total Jenkins user population. All told, it’s estimated there may be anywhere from 15 million to 23 million developers globally relying on Jenkins. CloudBees also noted the combined number of defined Jenkins Pipeline and other jobs increased during this same annual period, from 10,509,706 million to 20,664,054 million, with Jenkins Pipeline jobs demonstrating growth of 309 percent from last year.

    Noren said one of the primary reasons for that continued success is that unlike other CI/CD platforms that provide a highly opinionated framework accessible only as a cloud framework, the Jenkins environment makes it possible to deploy a more flexible framework on-premises or in a public cloud.

    Of course, there are still millions of developers that have yet to be exposed to any type of CI/CD framework. But as DevOps practices continue to become the primary method through which application development and deployment is increased, it’s now only a matter of time before most developers are working within the context of a CI/CD platform.

    In fact, it’s arguable that those organizations that don’t soon embrace CI/CD platforms will be overwhelmed by rivals capable of updating applications at rates that are increasingly being measured in days and hours versus weeks and months.

    — Mike Vizard

  • DevOps Chat: Cloud-Native Security with Twistlock CEO Ben Bernstein

    DevOps Chat: Cloud-Native Security with Twistlock CEO Ben Bernstein

    The rise of containers and microservices has given rise to a need for a different type of security. Ben Bernstein, CEO of Twistlock, believes cloud-native security is the answer. Fresh off another round of VC funding, Twistlock has big plans to advance cloud-native security in the container space.

    In this DevOps Chat, we talk funding, serverless and cloud-native security with Ben. As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Alan Shimel: Hi everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. I’ve got a really exciting chat guest and subject lined up today. I’m happy to be joined by none other than Ben Bernstein. Ben is the CEO founder of Twistlock. Ben, welcome to DevOps Chat.

    Ben Bernstein: Thank you, Alan. I’m really excited to be here. Thanks for inviting me.

    Shimel: Not as excited as I am to have you here. You know, as we were talking off camera, we’ve done other podcasts with Twistlock, but I don’t think we’ve had the pleasure of having you on. It’s a real pleasure. Ben, we’ve got some big news we’re going to break today. Twistlock has raised – is it a round C?

    Bernstein: Absolutely. Yes, round C.

    Shimel: Tell us a little bit about it.

    Bernstein: We’re really excited about it. It’s a $33 million round, which bring us to about $63 million in total money raised. It’s led by Iconic Capital, which is pretty a unique family office that’s probably the largest family office in the world, headed by some of Silicon Valley’s top entrepreneurs, which is a very – something that really made us happy to see that we got the interest of such an awesome funds. So we’re pretty excited about this, and having them join our board. It’s also kind of unique because we sort of reached a growth stage, which is first for me, as a CEO, it’s kind of an interesting to see how the company evolves – sort of the level of maturity we’re starting to hit, which is just exciting. It’s just like seeing your kids go to college or something, I guess. [laughter]

    Shimel: Well, look, my oldest son is leaving Friday for college. I know how that feels, Ben. So $33 million in this round, about $60-something million in total. As we were talking off-mic, I was telling you my experience with raising money. Raising money is never easy per se. When you have a good product, a good company, and the right space, it gets easier maybe, but it’s never totally easy. So congratulations on a sizable round here. It also coincides with a new release for Twistlock. Is that correct?

    Bernstein: Yes, we actually recently released 2.5, which was a pretty interesting release for us, because it updated some of the – or reinforced our investment in Cloud-Native, which is not just container specific, but also augments our complete suite for Cloud-Native computing. So there were some pretty extensive serverless additions there, AWS Fargate addition there as well as some interesting capabilities around forensics, but overall it was a pretty extensive addition to our suite. So we’re very happy about that as well.

    Shimel: So Ben, you mentioned an interesting thing and that is this concept of the whole Cloud-Native space is exploding. We have the Cloud-Native foundation, and all Cloud-Native tools and so forth. Originally, when I heard Cloud-Native, it was very cloud computing, AWS, Azure, that kind of cloud, but with the advent of containerization and Kuernetes and Docker and so forth, it’s really almost I don’t want to say dominated – or synonymous, but it’s so closely linked. From a security point of view though, Ben, where do you see the overlaps, and then where is the difference from Twistlock’s point of view?

    Bernstein: You mean between specifically serverless and –?

    Shimel: Yeah.

    Bernstein: Yeah, so at the end of the day, I think there are two types of application security companies. There are box companies and there are cloud companies. When you think about cloud, it’s basically – it embeds in it the concept that you don’t own the infrastructure. It embeds in it the fact that the people that get the resources get everything in a box. They get the networking. They get the storage. They get everything with a click, whether it’s a public or a private cloud, and it embeds in it the fact that you’re using microsegmentation. It’s about code reuse. It’s about a lot of good things that we all are sort of learning in the past I’d say 8 to 10 years, unless you’ve been working in Google or some of the companies that probably invented this space in house.

    Everything I just said is not about a very specific technology; it’s about specific concepts. These concepts are very disruptive to the way security is being built, and we at Twistlock, believed initially that _____ be the poster child of how existing security cannot protect containers, but when we’ve seen that, it’s not just about containers. It’s about other technologies that are being used by DevOps teams in modern organizations going through so to speak a digital transformation. We decided that we should really expand what we do to go beyond containers pretty early on, and go to really focus on Cloud-Native, which is a suite of technologies, that even includes VMs, but is all about giving or empowering these groups, DevOps groups, to be able to move fast and still secure their work loads.

    This is something that’s hard for them to do with seven different legacy products, where they’re trying to script their way somehow into putting something on the hardware firewall, plus virtual appliance, plus something that needs to – that has a concept of a server, or was built around a concept of a server, where in reality, it should have protected the app, not the server. But anyway, that’s – and so in this – when you think about it in these terms, serverless and containers, and even VMs, if you use them in a certain manner it’s pretty much similar. If it’s immutative, it’s declarative, it’s predictable, a lot of things that really change even the level of security you could wrap around it.

    Shimel: You know, Ben, I also wanted to make the point that so much of this technology is wrapped around the – it’s intrinsically linked with DevOps and a new way culturally of how companies approach not just application development, but specifically application security. I’m wondering – some Twistlock guys, 2.5 guy, your new version out, how does the whole DevSecOps thing movement manifest itself into real features and functionality that we see in the Twistlock suite?

    Bernstein: So when we created Twistlock, we realized that existing security was sold to say seven different people in the company. You take the storage person and sell him storage security. You take the network person and sell him network security. You take the server person and sell him server security where when in fact, everything you were trying to do is to protect your app. Maybe there were other people who you sold different security solutions. What we’ve seen is these five people are actually one person in the Dev Ops area. It’s one person that does a single click and – or several clicks and gets all these good things, but he’s in charge of that because he gets all these things from a single source – the cloud.

    In our bet, which went beyond just specific technologies, and it is kind of counterintuitive to security in general, we said that security had to actually contain multiple layers of security from the same suite. So there’s no point anymore in getting vulnerability assessment from one vendor and east/west firewalls from a different vendor, and anomaly detection from a third vendor, and _____ from a fourth vendor, obviously unless you have a point in it. Most DevOps team, as long as you could – as long as the product is good, they would be happy to get a suite that allows them to get all of these things from a single source.

    That’s one of the bets that we’re taking. It’s a pretty dangerous bet because security has not been that way so far. Luckily for us, it seems to – it seems to be paying off so far. We have hundreds of customers and are doing pretty well.

    Shimel: To say the least. I think you’re being humble. $33 million dollars more in the bank. The usual thing is you’re going to use it for sales or marketing and engineering and support, but specifically what do you – with this kind of rocket fuel in the tank, what we can we look for from Twistlock?

    Bernstein: Well, to be frank, if – I was at the last DockerCon and I saw that people are actually looking for real cloud-native. There’s a real need. If you look at the language, you see that people understand the need for cloud-native security, and what we really want to create is the – a complete solution that people would love and continue to use. So we need to continue to invest in the product. The product is the key. We don’t know how to play golf with executives. We haven’t been very successful at it generally. We really think that what really shines is a good product and a good support team to actually make sure the customers are happy and are using the product right, and that customers are smart, and that they can evaluate things and buy through the channels that they want to use.

    But we’re going to keep doing that, keep trying to make sure that our product is really the most complete solution possible. It gets challenging over time as customers move more workloads into the cloud. They have more demand. We need to excel at doing that, but we’re going to be very focused on making sure our products are – really excels and from that, we believe that given intelligent customers and a supportive team that supports the customer will continue to succeed. So not a lot of huge news there, but just given the demand and given the sophistication of Fortune100 customers, we need to keep – even keeping a product as is requires you to continue and grow just because of the requirements coming from customers over time. We need to do more than just keep the existing product as is. We need to really grow and support new technologies. So anyway, it’s a complex task and we’ll continue at it.

    Shimel: Absolutely. Congratulations, Ben. Over the years, I’ve had a chance to work with many entrepreneurs, VCs, successful business folks. Any one of them will tell you doing what you’ve done here with Twistlock, regardless of where the end game actually winds up playing out at some point, is really something to be proud of. So congratulations to you and John and the rest of the Twistlock team on both the new version as well as the significant new raise.

    As I mentioned to you off-camera, Ben, the time goes so quick where we’re pretty much right on the edge of our time frame here. Wanted to just quickly end up, for people who maybe aren’t as familiar with Twistlock, want to get a little more information, where could they go?

    Bernstein: We have tons of information on our site, Twistlock.com, about use cases, about customers, about cloud-native in general. I encourage people who’d like to learn more to go there.

    Shimel: Fantastic. Well, Ben Bernstein, CEO and founder of Twistlock, thanks for being this episode’s guest on DevOps Chat. Congratulations on all of the good stuff, all of the good news coming out of Twistlock, and continued success.

    Bernstein: Thank you, Alan, for having me. Thanks everyone for listening.

    Shimel: All right, a pleasure. This is Alan Shimel for devopsy.kinsta.cloud. you just heard another DevOps Chat. See you soon, everyone.

    — Alan Shimel

  • Platform9 Brings Workflows to Serverless Computing

    Platform9 Brings Workflows to Serverless Computing

    Serverless computing frameworks are widely regarded as the next big thing in enterprise IT because they are based on an event-driven architecture that makes servers, storage and networking resources dynamically available as needed using a programming construct known as functions. But DevOps teams are challenged in finding a way to orchestrate all those functions in concert with one another.

    To enable the orchestration of those functions, Platform9 has added support for Fission Workflows to its instance of a serverless computing framework. Platform9 CEO Sirish Raghuram says Fission Wokflows will make it possible for IT organizations to craft complex applications made up of thousands of functions.

    On the one hand, serverless computing frameworks promise to make DevOps easier by eliminating the need to provision infrastructure every time a workload exceeds whatever amount of capacity that has been assigned to it. On the other hand, attempting to manage what could easily become thousands of functions in an IT environment is likely to make DevOps even more challenging than it is today. While not a new concept, Raghuram says Fission Workflows provides IT organizations with a familiar construct for managing functions.

    Benefits of Fission Workflows include an ability to reuse functions as well as being able to upgrade entire related sets of functions all at once. There are also fault-tolerant capabilities that make possible to recover and restart a workflow in the event of an infrastructure failure.

    Platform9 is specifically making the case for a serverless computing framework based on Kubernetes clusters that can be deployed on-premises or in the cloud. Platform9 also provides support for containers on an instance of Kubernetes, and Raguham says the company expects that IT organizations will mix and match containers and serverless computing frameworks as they see fit. For example, a container might invoke a function via an API call to run a stateless process while Docker containers are employed for all the stateful processes that require access to primary storage, he says.

    Raguham notes the trouble with serverless computing frameworks put forward by cloud service providers such as Amazon Web Services (AWS) is that they lock an IT organization into a specific platform instead of taking advantage of a portable cluster technology such as Kubernetes, which is backed by the Cloud Native Computing Foundation (CNCF). Kubernetes also provides the added benefit of a common platform for both containers and serverless computing, he says.

    It’s still early days for the use of serverless computing frameworks in the enterprise. Nevertheless, it’s clear they will need to be managed from a DevOps perspective alongside cloud-native applications running on containers and platform-as-a-service (PaaS) environments and legacy applications running on virtual machines and bare-metal servers. Given the fact that none of these architectures is likely to supersede any of the others anytime soon, IT organizations would be well-advised to start crafting a DevOps strategy now on the assumption that the overall IT environment is about to become even more complex.

    — Mike Vizard

  • All Day DevOps: Bringing DevOps to the World

    All Day DevOps: Bringing DevOps to the World

    An Audacious Plan: Deliver DevOps to everyone.

    The global audience for DevOps is expanding faster than any one person or company can keep up with. While DevOps Days and other regional events provide invaluable support to their local communities, we wanted to create a global event, offering the very best lineup of speakers across North America, Europe and Asia.

    We also wanted to make sure that anyone, anywhere can attend. So, we set a high bar for our organizing team, and they delivered: $0 registration.

    By creating All Day DevOps as an online event, we are able to get many people to attend and present—many of whom ordinarily would not be available because of time or travel restrictions. We expect well over 1,000 people to attend throughout the day.

    15 Time Zones, 15 Hours, 3 Keynotes, 54 Sessions

    Nov. 15 will see the first truly global, online DevOps Conference: All Day DevOps. Starting at 9 a.m. Greenwich Mean Time/5 a.m. Eastern Standard Time and continuing through midnight GMT/8 p.m. EST, there will be three simultaneous tracks, each track containing 18, 30-minute presentations, for a total of 27 hours of presentations.

    Call for Papers

    We are inviting speakers from around the world to participate in this first-of-its-kind event covering 15 time zones. Timing for the conference is set for the EMEA sessions to begin at 9 a.m. GMT, then, at 9:30 a.m. EST, move the concentration of presentations to the east coast of the United States and ending with presentations on the west coast of the United States starting at 11 a.m. PST. All sessions will be recorded, but you will need to register for the event to have access to the recordings.

    The Call for Papers is now live. Please submit your paper soon. The deadline for submissions is Sept. 21.

    Conference Tracks

    The conference will host three tracks: Modern Infrastructure, Automated Security and CI/CD. We’ll have 54 sessions plus three keynotes on three tracks, running continuously for 15 hours.

    Track One: Modern Infrastructure

    Modern Infrastructure Track Hosts and Moderators: James Wickett, Signal Sciences, joined by Ernest Mueller, AlienVault and Karthik Gaekwad, Oracle

    In this track, we will be discussing novel architectures, approaches and tools for building out software and services. We are not looking for the standard approaches, but the way Infrastructure will be in the next three to five years.

    Track Two: DevSecOps & Automated Security — Living the Dream

    Automated Security Track Hosts and Moderators: Milton Smith, Oracle, and Shannon Lietz, Intuit

    You have a well-tuned development and delivery environment or you’re in the process of building one. AppSec is a top business concern. You moved DevSecOps from Big Foot and UFOs to reality, you sold the dream to staff, and now it’s beginning to pay off. This track explores DevSecOps tools and techniques to build a successful automated security program.

    Track Three: CI/CD — Continuous Everything

    CI/CD Track Hosts and Moderators: Derek Weeks, Sonatype, and Andi Mann, Splunk

    Continuous delivery is not magic, but it does take the right effort. The most successful practitioners have taken pragmatic steps to reduce cycle times, improve collaboration and build quality in without burning people out. This track asks you to share your frontline experiences of building CI/CD pipelines, aligning key stakeholders and measuring the results. Remember, what’s now an everyday experience for you is awesome to another pursuing that path.

    Conference FAQs

    How to I register to attend?

    Registration is open now at AllDaydevopsy.kinsta.cloud. The site will be constantly updated, sometimes multiple times per day, with the latest information. You can also follow us on Twitter under the handle @AllDayDevOps and using #AllDayDevOps.

    screen-shot-2016-09-12-at-4-44-16-pm

    How will the sessions be delivered?

    The sessions are delivered over Google Hangouts, allowing us to have an unlimited number of attendees on each of the three channels. All you need to deliver a presentation is a reliable internet connection.

    We are also arranging Slack channels for all sessions to host interactive Q&A sessions for everyone.

    If my talk is selected, can I post a notice or an article about the conference on my site?

    Not only is it OK, we would thank you profusely if you did. You’re welcome to use the banner and the conference icon if you need graphics for the article. Let us know when it goes up and we’ll give you a shout-out.

    Who is organizing All Day DevOps?

    The All Day DevOps Conference is organized by advocates in the DevOps community. We are working together to deliver a diversity of vendor-neutral sessions and speakers from around the globe to show practical usage and technical solutions of DevOps in small and large enterprises.

    • James Wickett, Signal Sciences
    • Derek Weeks, Sonatype
    • Shannon Lietz, Intuit
    • Milton Smith, Oracle
    • Andi Mann, Splunk
    • Mark Miller, Sonatype
    • Ernest Mueller, AlienVault
    • Karthik Gaekwad, Oracle
  • IBM BlueMix OpenWhisk Takes Infrastructure Out of the Equation

    IBM BlueMix OpenWhisk Takes Infrastructure Out of the Equation

    Thousands of people descended upon Las Vegas last week for the annual IBM InterConnect conference, where IBM shares its vision with customers and developers and makes big announcements. One of the biggest things Big Blue unveiled was BlueMix OpenWhisk, an event-driven programming service designed for a serverless computing environment.

    OpenWhisk uses an event-driven model, automatically executing code in response to external events such as incoming sensor data or designated triggers. (Event-driven programming is also called serverless programming, because the events themselves more or less become the foundation on which the programming is built.)

    Al Hilwa, program director of Software Development Research for IDC, declared the BlueMix OpenWhisk announcement to be one of the most interesting revelations at the IBM InterConnect conference. “This is IBM’s play in the hot area of serverless back-end computing supporting an event-driven application model like AWS Lambda, Google Cloud Functions and technologies from players like iron.io,” he noted. “This is the new face of PaaS, where developers do not have to worry about infrastructure.”

    I recently wrote that advances in DevOps increasingly seem to marginalize the “Ops” part of the equation, essentially making it obsolete: I noted that what you’re left with essentially is developers with the processes and tools to automate the infrastructure back end. Technologies such as containers and services such as AWS Lambda simplify greatly the process of programmatically generating, modifying and maintaining the underlying infrastructure.

    As I summed up in that article, though, Ops won’t really go away. Advances in DevOps and technologies such as serverless computing simply free operations teams. They can spend less time putting out fires or maintaining mundane configurations and focus more on big-picture issues that improve performance and help the company innovate.

    OpenWhisk is evidence of that future. It has the potential to transform IT and accelerate DevOps even more. Developers can develop and deploy applications faster and more seamlessly without the need to worry about the servers or middleware traditionally required. OpenWhisk will handle the necessary code.

    IBM suggested developers can use OpenWhisk to create microservices-based applications, where each individual task or component is developed and maintained separately. Different teams can operate in parallel on their individual elements.

    OpenWhisk joins other serverless computing platforms including Amazon’s AWS Lambda and Google’s Google Cloud Functions. As Hilwa pointed out, there are also emerging players such as iron.io. The unique value that OpenWhisk brings to the table is that it is integrated with the BlueMix platform, which means developers have immediate access to all of the apps, analysis and services BlueMix has to offer.

    IBM will open source the codebase of OpenWhisk itself. That isn’t a surprise, since BlueMix itself is based on open source code and IBM is a major proponent and benefactor of open source projects. The true potential of a tool such as OpenWhisk can be realized more quickly with the community at large helping to evolve it, but IBM can continue to act as consultants and provide deeper services for customers to help them maximize the value of OpenWhisk.