Tag: serverless

  • FaaS is Key to DevOps Efficiency

    FaaS is Key to DevOps Efficiency

    When AWS announced Lambda–a serverless Function-as-a-Service (FaaS) technology offering–the idea of encapsulating a specific task into a function that resides in the cloud was introduced into mainstream access.

    Now, with the rising popularity of microservices, DevOps is waking up the benefits of FaaS where it is used to build and maintain enterprise applications in agile environments. The move to serverless architecture using FaaS is one organizations are now increasingly likely to investigate in 2019.

    Given these industry realities, we need to ask ourselves what place will FaaS take in contemporary computing environments and how will its core efficiency proposition enable DevOps to flourish and improve experiences for users at every level?

    Back to Focus

    First let’s remind ourselves what any FaaS platform really does. It allows us to focus on developing and executing business logic because server provisioning and management is handled automatically at the backend. Developers can deploy applications into a space with zero server administration, yet with the ability to enjoy high availability and high scalability.

    The impact for DevOps is immediately apparent.

    Developers are able to work in a zone where they are essentially abstracted away from the servers their applications live and breath on. The services developers draw upon are event-driven and eminently scalable. Even if they have to scale by some massively parallel level of magnitude, server-side service optimization is handled at the backend by the FaaS vendor.

    At the same time, the cost structure is shifted and operations staff are able to oversee compute billing models based on actual execution of functions, as opposed to being dependent on the physical size of a pre-provisioned cloud server established at best guess size and core optimization parameters for compute, I/O, storage, analytics and so on.

    Speedier Implementation

    If we have so far looked at the FaaS efficiencies that reside at the backend server-side management element of the equation, let us also turn our attention toward the way FaaS allows developers to reduce the amount of time it takes to deploy code in a new environment.

    Adopting a FaaS-centric approach to application architectures allows the developer team to encapsulate specific software tasks into functions, hence the name. For a mortgage calculation application, for example, we can encapsulate functions such as interest rate calculations, payments, length of contract etc., and then place those functions in the cloud on a FaaS platform. The FaaS provider is responsible for the hosting of that function and also looks after the heavy lifting associated with availability and redundancy.

    The benefit to developers is a very rapid environment for deploying new code, getting feedback and iterating. The operations benefit is one of hosted happiness as the FaaS provider shoulders a significant administrative burden.

    FaaS and microservices are now increasingly viable options in any modern technology architecture and it’s important to distinguish between the two.

    Microservices are made up of self-contained elements of business logic designed to perform a very specific job. They are optimized for their single responsibility and can communicate with other services via application programming interfaces (APIs). Further, they can be developed, deployed and scaled independently without impacting other services.

    A FaaS-based approach is well-suited for transactional workloads where code is run periodically. This is also a technology that is quicker to establish, as and when needed. A FaaS function might also make a call to other application logic that (in the case of our mortgage example) calculates interest rate and so on.

    FaaS Challenges

    Like any still-nascent technology, FaaS has its functionality flaws and challenges. The automated nature of foundational provisioning in FaaS is great news, but it’s not a panacea.

    Why? For one, DevOps teams will have limits on the debugging capabilities for applications that run on FaaS DNA. Also, functions are instantiated and then de-instantiated as needed, which requires time, especially for a cold start. This process can cause unwanted delays in time-sensitive operations. The transient nature of FaaS also impedes state preservation among dependent functions, which requires careful design considerations.

    FaaS is a place where the burden of server resources control has been shifted. But there’s no such thing as a free lunch and this means DevOps won’t be able to interject some level of application monitoring function at the server level itself. You’ll need to know more about your FaaS-based application before you FaaS it up.

    We must also remember for any distributed software architecture, there’s an up-front responsibility to design to accommodate the limitations and increasing options available in modern services.

    The FaaS Road Ahead

    Examples of FaaS now extend beyond AWS Lambda, we can also look to Microsoft for Azure Functions, Google for Cloud Functions, IBM OpenWhisk, Oracle Functions, Fn Project and IronFunctions with its Iron.io platform.

    This sector of the software landscape is guaranteed to grow over the coming years. FaaS can be an appropriate option in an overall software architecture, but there are specific limitations, so choose wisely. Observing the evolution of FaaS over the coming years will be a fascinating process.

    — Mike Duensing

  • Why Modernizing Security is Like Visiting a Fast-Food Restaurant

    Why Modernizing Security is Like Visiting a Fast-Food Restaurant

    Fast casual restaurants are taking over the food industry. Today’s consumers want quality and speed, and the brick-and-mortar model offering immediate service paired with quality ingredients perfectly fits the bill. It’s the new, modernized dining experience. You can also argue that the same modernization taking the food industry by storm is happening in the security sector.

    Simply put, fast-food restaurants know what their customers want: food that’s served hot, fresh and quickly–all while being made to order. And while the needs of a fast-food customer may seem far from the security needs of an organization, it isn’t too far off. Just like a fast-food customer, DevOps teams are hungry for a streamlined process. However, in their case, this doesn’t come in the form of a fried chicken sandwich; rather, an app infrastructure that is low-latency, secure and brings visibility.

    According to the 2018 Verizon Data Breach Investigations Report, web application attacks are the leading source of data breaches. This suggests security procedures are not keeping up with modern systems and vice versa, which means they’re not keeping up with the modern customer, who has increased security needs due to demands for fast, interactive, web-based experiences with vendors. From food service to security, many industries are learning that, to succeed today, you’ve got to combine the old with the new.

    As technology evolves, systems must as well. When it comes to security, it does not make sense to continue using a legacy WAF built for a decades-old line of defense. Today’s technology and applications require next-gen WAF systems that can keep up with the changing infrastructures and the evolving threat landscape. The risk is too great to sit back and do nothing.

    Security teams today often find themselves either supporting new infrastructure initiatives or inheriting legacy applications and systems. Determining where an application is running can be a challenge. Rather than simply pointing to a rack of servers to locate an app, security professionals now must look to the cloud. However, this presents another obstacle: container orchestration. Kubernetes or otherwise, the options are not always clear-cut.

    A modern infrastructure mix is made up of many parts (much like a layered chicken sandwich): cloud, containers, hardware, platforms—and sometimes serverless. Flexibility and deployment options are essential to defending applications and APIs across multiple components and delivery stacks. Typically, security teams end up in a balancing act of supporting new infrastructure plans while taking over existing legacy systems and applications.

    To be adequately protected, security teams must evaluate defensive tools, open source or commercial, for use in:

    • Major cloud providers (e.g. AWS, Azure, IBM, GCE)
    • Container platforms (e.g. Kubernetes, Docker)
    • Hardware and web servers (e.g. load balancers, NGINX+)
    • Serverless options (e.g. API gateways)
    • Platform services (e.g. Heroku, language plugins)
    • Cloud-based deployment models (e.g. hosted cloud WAF)

    The modern world is ever-evolving and the definition of “modern” changes as new technology is introduced. Fast-food chains have evolved over the years and, in turn, moved the food industry forward with the introduction of fast, casual and reliable options. The companies continue to evolve to meet the customers’ demands by introducing delivery services, unique rewards programs and leading mobile apps.

    The security world can learn a thing or two from the fast-food chains’ commitment to continued business evolution. Much like the way fast-food customers are quick to jump ship if they don’t see the selection they want, legacy WAF customers are learning they can make a change to other security solutions if features and infrastructure aren’t evolving.

    The simple truth is legacy WAF solutions can’t accommodate today’s technology and applications, exactly how traditional fast-food can’t keep up with customers’ growing demand for tasty yet quick meal options. This leaves proprietary data exposed and vulnerable to attacks. It’s time for security leaders to take action and upgrade their systems while getting their teams up to speed without sacrificing security of their vital assets.

    — Jonathan DiVincenzo

  • Twilio Adds DevOps Tool to Invoke Communications Services

    Twilio Adds DevOps Tool to Invoke Communications Services

    At its annual SIGNAL conference, Twilio today launched an initiative intended to make it easier to embed a variety of communication services within an application in the context of a DevOps process.

    Quinton Wall, senior director of developer marketing at Twilio, said the open source Twilio Command Line Interface (CLI) tool, now available in beta, will make it possible to incorporate Twilio cloud services within a larger DevOps toolchain.

    Twilio provides developers will access to a range of SMS, audio and video services that can all be incorporated into applications via application programming interface (API) calls. The pipelines created using those APIs now can be stored and shared via GitHub.

    The CLI tool also makes it possible to extend those services via Plugins, said Wall. In addition, DevOps teams can invoke an existing serverless computing capability from Twilio to invoke the company’s services using functions, added Wall.

    It’s not clear to what degree cloud services such as Twilio will be invoked using serverless computing frameworks going forward. Many of the capabilities that developers once were required to embed in their applications are set to become external services that applications call when needed by launching a function. While that approach makes the application more efficient, it puts additional pressure on IT teams to manage all the calls to various serverless computing frameworks within the context of already complicated DevOps pipeline.

    While serverless computing frameworks are still an emerging IT platform, the rate at which serverless computing frameworks are being adopted suggests the day when they are commonly included with a DevOps toolchain is not very far off.

    In the meantime, Twilio is clearly hoping that by making its communications services easier to invoke within the context of a DevOps toolchain will increase consumption. Twilio has long exposed REST APIs, but the CLI tool will make it easier for organizations to standardize on Twilio communication services across a range of applications. By exposing those services via APIs and a CLI tool, Twilio is betting that the days when end users opened a separate application to communicate are numbered. Instead, most users will invoke communications services within the context of, for example, a business intelligence application that is already open. That approach also eliminates the need to invest in dedicated network hardware to run unified communications applications that, from an API perspective, are often more difficult to invoke programmatically.

    As DevOps processes become more widespread, it will be interesting to see how many other providers of cloud services start to routinely make available CLI tools. Arguably, any provider of a cloud service that doesn’t make a CLI tool available will find themselves on the outside of a DevOps process looking in. Service providers that provide a CLI tool will be preferred among organizations that embrace best DevOps practices. In fact, the challenge DevOps teams soon may face is not whether there is a CLI tool available, but rather determining which of the many available best fits within the DevOps processes they have adopted.

    — Mike Vizard

  • 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

  • Unravel: A System Architect’s Guide to Data Operations

    Unravel: A System Architect’s Guide to Data Operations

    Big data is an older fashionable term that, when combined with agile methodology, AI and ML and analytics, has become a powerful trend once again in data operations (DataOps). If you’re a systems architect, it pays to understand the philosophies, benefits and tools to power DataOps and improve your data-driven applications. This article serves as a guide to define enterprise architectures that support the needs of an organization.

    Inside Statistical Process Control (SPC)

    The DataOps Manifesto defines a set of key principles to guide systems architects and implementation teams. In summary, they focus on the customer and analytics, driving positive change through a continuous improvement process that relies on both teamwork and automation to help drive efficiency and overall data and system quality. This is based on statistical process control (SPC), which is a quality-driven approach to using data and associated statistics to monitor, control and improve systems and processes. Quality, in this sense, translates to maximum application uptime, increased usefulness to the customer and reduced waste in terms of delivery time and resource usage.

    Data is king in SPC, and most data-driven application architects go through a set of phases when they design systems. These phases include:

    • Data Discovery: Knowing the sources of data used by applications, as well as identifying new sources of data about your applications and their environment. This includes performance statistics and other systems and process measurement data.
    • Data Relationships: From the data and their sources, knowing the relationships and hidden value in your data is the next phase. This is the realm of big data and analytics where you search for business meaning buried in the data to be used to expand your offerings to customers while also enhancing and improving the customer experience.
    • Data Monitoring: This means you want to ensure system uptime by monitoring your data-critical systems (e.g., data feeds, databases, analytics and so on), but it also includes automation of the first two phases above.

    In line with SPC, performance data is used to ensure that your systems and their processes are stable, with the uptime and responsiveness needed to meet customer demand. To achieve this, the reach of DataOps extends from the data scientists and business analysts within your organization who solve business problems with data and algorithms, through to the database administrators and the developers who work with that data (e.g., ETL) and build applications from it.

    From here, DataOps gives you insight into value discovery, turning these into new methods and tools, with an emphasis on continuous refinement. Tools and techniques will help you automate data mining, the discovery of potential performance improvements, identifying areas to create more efficiency and lower costs and prepare you for the future in terms of business and architectural needs.

    Leveraging DataOps: Automation Is Key

    Putting feedback loops in place helps to automate the entire data flow, from business intelligence, where tools are used to help data analytics processes, to data science, where new mathematical and architectural approaches are used to drive deeper understanding data, to developers and operations staff, where the data is aggregated into applications and further measured to drive new value back through this process.

    Automation is used to build efficient feedback loops without overburdening your IT staff. In turn, automation tools are used not to replace your analysts, data scientists, developers or other IT personnel, but to enhance their jobs and make them more efficient at what they do. As data production and consumption continue to grow, your organization’s ability to discover hidden value in this data and drive it through to real system improvement will be a key competitive advantage.

    AI-Driven DataOps

    While data visualization is important to effective DataOps, displaying graphs and pictorials can go only so far. Gaining actionable insight into metrics is what drives improvements in performance and efficiency. To remove the potentially error-prone manual approach to achieve this, organizations are leveraging an AI-driven approach to DataOps. This helps discover hidden dependencies between applications and their resources (e.g., databases and other data sources) along with their users and their needs, providing unified visibility and operational intelligence to optimize your entire ecosystem.

    AI can help you dive deeper into the effectiveness of your data, going beyond operational efficiencies to identify improvements to code, overall system architecture and the configuration tools and frameworks in place across the cloud or data center. Going further, AI-driven DataOps can help you optimize your consumption of cloud-based resources or identify key components to migrate (with recommended changes to deployment) when moving to the cloud.

    The Big Picture: Cloud, Microservices, Serverless and DataOps

    As a systems architect, you need to maintain a big-picture view of the data, systems and processes used within your organization to best serve your customers. This means you need to understand the entire application ecosystem to communicate and simplify your system and data operations. Tools help provide and maintain a 360-degree view into the performance, interactions and dependencies between components in your software systems and data workflows, along with all of the storage, compute and network infrastructure that supports them.

    To enable the value in DataOps and drive visibility of the data and interactions within your systems, adopting newer architectural approaches can help. For instance, breaking apart monolithic applications using a microservices approach helps drive real value throughout your technology ecosystem; it helps improve the makeup and velocity of your development teams, improves the benefits of operational efficiency, drives a test-driven approach to development (since these services are more easily verifiable) and helps enable cloud deployment.

    Other approaches such as the use of containers and serverless architecture help remove system dependencies from implementation, reducing the impact of deployment changes on your applications’ code. With all of these changes, the data orchestration and workflows without your applications (including your customers’ usage of this data, in some cases) become more apparent and measurable.

    Call to Action: Leverage Tools and Frameworks

    DataOps helps operations staff, app developers and enterprise architects reduce the complexity of delivering reliable application performance. Whether you’re new to DataOps or have been on board for some time, knowing the tools and frameworks to help drive both your architectures and operational control is key to success. Tools such as those from Unravel (see Figure 1) provide monitoring solutions that map dependencies between applications and their data sources, and all of the components in between.

    Figure 1: DataOps tools such as the one from Unravel should support your existing implementation and technology choices, while supporting the three phases of DataOps work.

    The tools you use should automate the discovery of value and optimizations to be made, where possible, from the viewpoint of business owners, IT operations staff and the data scientists and developers defining and building the systems. All of this should be achievable regardless of the platforms, frameworks, languages and cloud providers you use to enable your applications and users. Finally, make sure your DataOps approach and tools support your organization in the future, with support for continuous improvement of overall architecture as well as data processes.

    This sponsored article was written on behalf of Unravel.

    — Eric Bruno

  • Keeping NoOps From Going Rogue

    Keeping NoOps From Going Rogue

    “We’re NoOps—everything is in the cloud and we have no infrastructure to manage.” Before running that victory lap and shifting everyone to the dev side, consider several NoOps risks carefully. I’m really thinking about teams using all-SaaS stacks, especially in martech, edtech and other areas. However, the rise in microservices and serverless means more teams are leaning toward NoOps. At least a few people on your team should always watch for rogue issues on the ops side of the equation.

    Locked-in Vendors

    Risk: Cloud-based tools in the same category rarely have the same functionality. Once one is selected, you’re committed to its specific features. Moving away from a tool may mean dropping a popular application feature or changing workflow with coding to recreate functionality.

    Mitigation: Evaluate unique features and customized data fields carefully before use. Solving data format differences is relatively easy for common fields. Look for tools with well-documented APIs and integrations or connector support for analytics. If there are no integrations out there, that’s a red flag.

    Ghosting

    Risk: Lock-in becomes a big problem if the vendor ghosts. SaaS startups often meet one of two fates: they are acquired or they crash and burn. A tool critical to your workflow may disappear overnight. In the acquisition scenario, you may have some time and support in migrating from your tool to its successor.

    Mitigation: Always have a Plan B for every cloud-based tool in your stack. Competitors are introducing new tools frequently. A trade study done two years ago may be completely obsolete on today’s fast-moving landscape. Proactive migration to newer solutions may reduce vendor risk and improve features.

    Limited Observability

    Risk: Overheard in a conference recently—Those who develop the code are more motivated to build in useful observability for those in operations if those folks are the same team. In NoOps, that’s not in play. If a cloud-based tool in your stack is down frequently or providing strange results, it may be very difficult to tell what is happening. Observability is often replaced by faith that the SaaS vendor has done its job and you aren’t experiencing a corner case it hasn’t tested.

    Mitigation: Observability and monitoring aren’t the same, but when you don’t have observability inside SaaS tools, monitoring helps. Application performance management (APM) tools are emerging with new ways to build instrumentation around microservices. Create test cases with synthetic data to check your functionality—you’ll need these to provide evidence for the vendor in any bug report.

    Unoptimized Workloads

    Risk: You’re also often at the mercy of the SaaS vendor when it comes to speed of results. It’s a common tripping point to pilot a SaaS workflow with a few users and test cases, and then find out it doesn’t scale when everyone is brought in.

    Mitigation: This is one the biggest NoOps risks where ops expertise pays off. Where is the problem, exactly? Application problems may be candidates for workload acceleration—such as running on a GPU (or FPGA) enabled cloud instance. Reporting problems may be better-suited for an analytics tool, which can be run offline with extracted data.

    Tangled Analytics

    Risk: Every SaaS tool reports different metrics in different ways. Worse, users in a multi-cloud environment face learning and visiting multiple applications to look at data. Different applications report similar facts using different terms. As the tool stack and data sets grow, it takes longer and longer to analyze data.

    Mitigation: Dashboards pay off early with one destination for data across the stack. Earlier, I mentioned the need for integrations or connectors—this should be a requirement for tool selection, both in the stack and the analytics tool. Deciding on which KPIs to track in the dashboard also focuses conversation and minimizes digging.

    Closing NoOps Risks

    There’s also the big topic of multi-cloud security and compliance, probably worth a series of posts by themselves. An Ops team working proactively in tool selection can comprehend many security risks before committing to tools and exposure. More value unfolds over time, as the security posture evolves with discovery of new threats.

    The tech pendulum is always swinging. For many organizations, NoOps swings the pendulum a bit too far from DevOps and leaves risks open. A better philosophy is MinOps, where a small team is deployed, watching for and even anticipating problems.

    I’d be interested to hear if you’ve tried NoOps and been successful over time, or if you reverted to a MinOps approach.

    — Don Dingee

  • DevOps Chat: Aqua Security Talks Funding, Security in a Cloud-Native World

    DevOps Chat: Aqua Security Talks Funding, Security in a Cloud-Native World

    Aqua Security, one of the leaders in container and cloud-native security, recently announced it has raised $62 million in a “C” round of investment, led by Insight Partners.

    In this DevOps Chat, we speak with Rani Osnat and Andy Feit of Aqua Security about how this validates the cloud-native security field that Aqua has helped develop.

    The video of our conversation is immediately below, followed by the transcript of our conversation. An audio version is also available on Soundcloud.

    [videopress 1pfe0tRG]

    Transcript

    Alan Shimel: Hello, everyone. It’s Alan Shimel, devopsy.kinsta.cloud, Container Journal, Security Boulevard for MediaOps and I’m really happy to be joined by my friends from Aqua Security. Charge of product marketing, we’ve got Rani Osnat, and, in charge of go-to-market, Andy –

    Andy Feit: Go-to-market, that’s right, Alan.

    Shimel: – none other than Andy Feit. Both of these guys are familiar to our audience or you’re both familiar to the audience – you’ve been on – but, guys, first of all, congratulations, mazel tov, whatever you wanna say. Big news today with Aqua. You guys raised a Series C, I believe it is, for $62 million.

    Feit: Yeah, thank you, Alan.

    Rani Osnat: Thank you, Alan.

    Shimel: Congratulations. So let’s talk about what this means, guys. So, first of all, it looks like this round was led by Insight Ventures, correct?

    Feit: Yep.

    Shimel: And I don’t know if we know; who is the Insight partner kinda leading the charge on this?

    Osnat: It’s Jeff Horing, was the _____ –

    Shimel: So I know Jeff and he’s one of the senior people there. Will Jeff be joining the board of directors?

    Feit: Yeah, so Insight will have a board seat.

    Shimel: Okay. Will it be Jeff, though, or you don’t know at this point?

    [Crosstalk]

    Osnat: Yeah, we’re not sure that it’s gonna be Jeff.

    Feit: We’re not positive, yeah.

    Shimel: Okay. I don’t mean to ask any trick questions, so don’t worry. So, Andy and Rani, you know, what I thought was interesting in reading the release was, yes, Insight did lead this round for $62 million, but a couple of things to note. Number one, your existing ventures, Lightspeed, Microsoft or M12, M7, whatever they call it –

    Osnat: M12, _____.

    Shimel: – Shlomo Kramer. You know, your existing venture investors all participated in this, correct?

    Osnat: Correct. Yeah.

    Shimel: And that says something, right? People believe in it enough to keep writing more dollars into it. Kudos to the Aqua team ’cause that does mean something.

    Osnat: Yeah, and it has been like that in all previous rounds as well, so we’ve always had the existing investors continue to participate. And I think, from their perspective, obviously, this is – they’ve taken – especially the early investors, like Shlomo Kramer and then TLV Partners, have taken a risk, investing in a very early-stage startup with an uncertain market. And now a lot of that risk is gone – you know, you can never know, but it’s a much more solid proposition than we had _____ _____ ago –

    Shimel: Well, it certainly less risky than a raw startup, but, you know –

    Osnat: It’s less risky, and so they deserve it.

    Shimel: – from an investment point of view, when they – it’s almost doubling down, when they continue to participate. Right? That’s saying, “I believe in this enough that I don’t wanna be watered down in my stake in the company, and so I’m gonna invest my pro rata or per-capita share so that my stake in the company remains constant, not decreased or watered down as they raise more money.” So it is very significant.

    The other thing I just wanted to mention is, hey, this brings the total raised, I think, to $100 million, maybe a little over $100 million.

    Feit: Just don’t round down, yeah.

    Shimel: I was doing the math on my fingers; I ran out of the toes, but I knew it was close. But the obvious question then becomes “So does this move Aqua into a unicorn, where you have a valuation of a million-plus?”

    Feit: Yeah, we’re not really sharing the details on the post-money valuation here. One of the nice things about being a privately-held company: you don’t have to share all those details. But, obviously, the number’s more than $100 million and we’re excited about bringing in a new investor that’s actually more than just bringing money to us. And I think what’s great about Insight is how involved they are, how well they know the space, the introductions they can make to partners as well as end-user customers. And this is really – they are a late-stage investor that knows what it takes to make a company successful.

    Shimel: No doubt about it. As we were talking off camera before, I have a relationship with Insight for a number of years now and, look, I’ve seen them invest in many companies that I’m very familiar with – some of them, I’ve worked with. Companies like FireMon and JFrog and Tricentis, Aquanow, and others. So, I mean, their record kinda speaks for itself. And I will tell you, more than just writing a check, I’ve seen firsthand, right, what they’ve done. I mean, frankly, we’ve talked about working with them here at MediaOps, in doing something for their whole portfolio, right? And great company. You couldn’t pick a better partner, in my opinion.

    Feit: We definitely feel that way and it’s impressive how well they know the space. Through the due diligence process and even –

    Shimel: No doubt about it.

    Feit: – here at the meeting, they’re digging in. And the fact that they spoke with our customers, they met with our team, they looked at our product, they went through it – it’s a testament to how far we’ve come and we’re excited about that.

    Shimel: Great. So let me pivot now. So, again, congratulations on the raise. That’s a significant amount of money. It means you guys can do some great things. In reading over or perusing the release, though, I saw some other kinda subtle changes in messaging, and that is I knew Aqua or many of us may know Aqua as a container security company. And now I see the messaging changing to more a cloud-native security company. Let’s talk about that. What does that mean, Rani?

    Osnat: Yeah, I think, when we started out, the market was different, in terms of adoption and also in terms of the technology landscape. A lot of the technologies that are now maturing were really experimental at the time – and we’re not talking about a long time ago; it’s three and a half years ago – but things like serverless, for example, that are catching on. They’re not as big as containers yet, but, if you believe some of what the proponents say, they will be bigger.

    And, in general, I think there’s a trend to look at this cloud-native space, for lack of a better term, as something that is supporting the next generation of application development, application deployment, and runtime environments, where cloud-native doesn’t – it’s not equivalent to cloud, right? I mean, you could run things in the cloud that are not cloud-native and you could run cloud-native applications on-prem as well. But the whole notion is that you support this very Agile, microservices environment that is portable, interoperable, and you can update it very frequently. It’s very resilient – you can update different pieces without impacting other pieces.

    And the benefits to enterprises that adopt these technologies are huge, and so that’s why it’s catching on. And we’re at that stage where we see not just the breadth of adoption across the industry, in terms of the number of companies that are actually using it, but also how deep it goes and how wide the adoption is within a given company. So we’re still at an early stage, but we see how a lot of enterprises like banks and insurance companies, not the tech industry itself, are looking at these technologies as strategic to their objectives – digital transformation, customer centricity, all those things.

    Shimel: You know, I was telling someone in the office here this morning, “We live in such interesting times if you’re a tech person.” Right? I think bank to my first Web hosting company in 1995 and what it meant to rack up a server.

    Osnat: Right.

    Shimel: Right? Set up a server for someone. My ops people walked around with tool belts, with pliers and screwdrivers, right, ’cause you had to literally screw in the server into the rack. It’s a different world; it’s an amazing world. Here’s another just something I wanna throw out at you: when we talk about things like serverless and we talk about what Kubernetes brings to the picture, it almost – there’s a place for everyone here. It’s not just the cloud, like we’ve seen with AWS or Azure or Google or Alibaba or – you know, the data center is back.

    Osnat: Right. Yeah, I –

    Shimel: Right? And there’s now _____ serverless stuff, right?

    Osnat: Yeah.

    Shimel: And it’s still native.

    Osnat: Yeah, absolutely, and we think if you really kinda distill it, from a technology standpoint, to one thing, we’re talking about a complete abstraction of the application layer from the underlying infrastructure. Right? So that’s –

    Shimel: That’s it right there. Mm-hmm.

    Osnat: – moving into a serverless world, but “serverless” not in a narrow sense of serverless functions that we have today but “serverless” in the wider meaning of the word, where you really don’t have to manage any servers. And any technology that aligns with that concept is legitimately cloud-native and we need to support those technologies.

    And, even today, there are many choices, right? You can do everything from running containers on VMs to running containers on bare metal to using container-as-a-service type solutions or serverless containers, like Fargate and ACI, and, of course, serverless functions. And there will be a lot of things in between that. We’re already seeing some technologies that are still very early-stage, like micro-VMs or hybrid container VMs, and this will all have a place because, ultimately, organizations will choose the technology that serves them in the most optimal way, without necessarily being married to one particular technology.

    Feit: And I would just add, Alan, I think the common theme between these technologies is the dynamic nature of the infrastructure and the ability to spin up, whether you’re spinning up a VM or requesting a microservice run for 70 milliseconds on a function. It’s happening over the course of the day, over the course of an hour, over the course of minutes. That network is changing and your security infrastructure needs to understand that. And the old-school models of securing these platforms didn’t work before and it’s only getting harder with things like microservices and moving to serverless architectures.

    Shimel: No, I agree. I think Rani hit it, actually, right on the head. We’re just seeing this abstraction where that whole infrastructure is so liquid, right, and so dynamic that you almost – you need to secure it, obviously, but the mission of securing the application, irregardless, wherever it’s _____, of the infrastructure, is a mission in and of itself as well.

    Feit: Which means you need to understand how _____ _____ _____.

    Shimel: And you still have to play nice.

    Feit: Yep. Yeah, you need to understand the application part of it, go with it wherever it’s running, and that’s really the magic of what Aqua does.

    Osnat: Right.

    Shimel: Yeah. Well, and I think that that is the magic, right, and that is the mission. Go with it wherever it’s running. Let me turn back. So, you know, some fresh fuel in the tank. What does the $62 million mean? Let’s talk about it just in terms of go-to-market with you, Andy, but, Rani, let’s talk what does it also mean in terms of product? In this new – I mean, one could say that – saying, “Hey, we’re gonna secure cloud-native. Gives us a bigger surface to play on, a bigger playground to play in.” Go-to-market’s a challenge, right? Both? Let’s hear.

    Osnat: Right. Yeah, I mean, so we’ve been – one of our key advantages in this market has been platform support and being able to support different clouds, orchestrators, operating systems, and modalities of cloud-native, right? And, as we see things right now, the market is not – it’s been consolidating around Kubernetes as the orchestration platform, but, at the same time, there are many different flavors and there are different dependencies, on where you’re running, et cetera, that have to be addressed.

    So we already are supporting a very large matrix of different technologies and combinations of those technologies. And, as the market continues to hold, we’ll need to continue to track that, so not just support them but actually provide deeper security controls at each level and at each step of the way because we’re not only a container security solution, as you pointed out earlier, but we actually provide this support for various types of cloud-native technologies, various pieces of the stack, and also the full life cycle. So, starting from their early stages of development and CI/CD, going all the way to production environments. And this requires investments in R&D.

    Additionally, we also have been investing in open-source tools, specifically around Kubernetes, and we will continue to do that and not only expand the capabilities of those tools that we’ve already put out there in the market but also add new tools. And we do that as part of our philosophy of educating the market, getting out tools that anyone can use, and then, when they get to large production environments, they’ll probably come to us for a commercial solution, with all the benefits of commercial interoperability and support and all that. So that’s – part of the money goes there, obviously.

    Feit: And part of the money definitely goes out to build the infrastructure, whether we’re talking sales globally. We’re working with some of the largest customers – companies in the world today and they have a global presence, but, as we go to market and look at growing the business, we have a proven model at this point. I mean, that’s what happens when you get to this late-stage investment. They’re looking for “Do you have customers? Could you do more of them if you had resources in various countries? Could you scale out more by solving more of their problems across divisions and departments in those enterprises and up-sell and cross-sell?”

    And then the support infrastructure. One of the things that has really differentiated Aqua, when we win our business – and we’re in a competitive marketplace, but one of the things that really drives us is our ability to be on site with a customer, to support them through their deployment, to be truly invested in their success and integrating with their CI/CD pipelines, integrating with their secrets management, integrating with their SIEM tools. Our solution is not standalone; it’s not a double-click install of a SAS solution. This is part of your entire application development life cycle and it requires resources, so we’ll be – there’ll be people, as part of those organizations, that help ensure the customer deployment is successful.

    Shimel: You know, I think Aqua is kinda taking the lead on this cloud-native security. Of course, we all at KubeCon in Seattle a few months ago. There’s another one coming up in Barcelona in – was it May? The end of May, I think.

    Feit: May 20th. Believe it, it’s on our schedule.

    Shimel: Yeah, no, us too. I think I fly out the 18th. We’ll talk about it. But, you know, I mean, we saw at KubeCon in Seattle this buzz, this palpable excitement – it reminded me of AWS Reinvent five years ago, right? Before the – when the cool kids still there. Where do you think we go? Are we at – I guess, are we at the top of the hype cycle here? Do you think it’s just starting? Where’re we going here?

    Feit: It’s still early, I think. [Laughs]

    Osnat: It’s not even close to the top. I mean, so KubeCon in Barcelona is gonna be – they’re expecting 10,000 attendees.

    Shimel: Wow.

    Osnat: Yes.

    Shimel: I didn’t realize it’s that big.

    Osnat: In Europe, _____ _____ _____ –

    Shimel: Yeah, that’s great to hear.

    Osnat: – _____ people coming from all over, et cetera. These European events are typically less well-attended than the US equivalents, so the last KubeCon in Seattle, I think, was 8,500, which was about double what Austin was the year before, and now they’re doubling Europe. So that’s, obviously, a very promising sign. But not only that, we see a lot of companies that are new to this space, new to Kubernetes, new to containers, new to serverless. And, sometimes, we get leads on our website – people who’ll purchase – and you can tell they’ve already done their homework, so these are not clueless people who are just kicking the tires, that are trying to learn the basics. They’ve already done that and now they’re actually looking for a solution because they know that they’re going to production, with their environment, in – whatever – six months, three months, nine months.

    And so that’s a level of maturity in the market that we didn’t see until recently. And also just the number – I mean, the sheer number of companies that are getting involved is huge and CNCF membership, including end-user organizations, is growing. So all of these are indicators to where it’s going. And I think Andy also wants to say something about our presence at KubeCon.

    Feit: Yeah, two things. I would also – before we talk about KubeCon, I think the other indicator is that most of the application workloads that are out there today are still very much in the data center. A lot of them are still monolithic applications; they haven’t all migrated to the cloud or, if they have, maybe they were done with a lift-and-shift. So I think we’re talking about a market that is poised for significantly more growth and we see a lot of different indicators of that. One example is our customers who deployed, say, a pilot project or a handful of applications one or two years ago are now asking us for enterprise-wide licenses and scaling this out to be “This is our cloud-native platform. We’re gonna do everything on this.”

    But, at KubeCon this year, in Barcelona, as we did in Seattle, where we did a pre-day event called “KubeSec Enterprise Summit,” we will be doing the same thing in Barcelona. You can register on the CNCF site. When you register for KubeCon, you can sign up for KubeSec Enterprise Summit, which is really an event built just for large-scale enterprise customers rolling out into Kubernetes in production. We’ll have customer speakers; we’ll have an analyst speaker; we’ll have panels. It was a terrific event, very positively reviewed in Seattle, and we’re repeating that now in Barcelona on the 20th of May.

    Shimel: That’s great news. You know, and one thing – look, I’m guilty of it; I think you guys are guilty of it too – we call it “KubeCon.” It’s “cloud-native con” too. Right?

    Feit: Absolutely. We do tend to – for those of us who’ve been in the market –

    Osnat: It’s like for a while.

    Feit: Yeah.

    Shimel: No, no, I do it. I’m guilty as charged, but I think there’s gonna come a day where cloud-native maybe is bigger than Kube itself, right?

    Osnat: Yeah. Well, I think it already is, in a sense, right? I mean, Kubernetes is just – it’s a bit like a fleet. You have a – Kubernetes is the aircraft carrier and then you have everything that surrounds it, the frigates and the destroyers and the minesweepers and all of that.

    Shimel: _____ and the battleships. Absolutely.

    Osnat: I think that you can tell I play – I used to play _____ –

    Shimel: I can tell that. Right.

    Feit: And the other thing that I think it comes down to, it’s just harder to say “cloud-native con.”

    Osnat: That’s true.

    Feit: It’s got too many Cs and Ns and _____ –

    Shimel: “KubeCon” does roll. You’re right.

    Osnat: Why don’t we call it “KubeCon cloud-native con”? Not “cloud-native con” or “KubeCon.”

    Shimel: Absolutely. Hey, guys, I know you’re coming to us from Madrid today. You’re at an Aqua team meeting, and so I appreciate you carving out some time, but I wanna be respectful as well. I know you only had 25, 30 minutes, so. First of all – or last of all, congratulations.

    Osnat: Thank you.

    Shimel: You and the whole Aqua team. I tend to think of you two as Aqua, but I know there’s more people behind it.

    Osnat: I mean, _____ _____ people behind this wall. I don’t _____.

    [Laughter]

    Shimel: Yeah. But congratulations to both of you. Congratulations to the whole Aqua team. It’s gonna be interesting to see how it plays out. As I said earlier, we live in interesting times in tech, so I will see you both in KubeCon in Madrid? I mean, in Barcelona.

    Feit: In Barcelona. And if –

    Shimel: In Barcelona. We’re doing videos there for Digital Anarchist, so we’ll have you in and we’ll talk some more.

    Feit: I will be at DockerCon before that if you’re going to San Francisco, so _____ –

    Shimel: I’m not at DockerCon. I have to go to Iceland. But –

    [Crosstalk]

    Feit: All right. Great talking to you again, Alan.

    Shimel: There’s only so many conferences that I can do, but we try. But we’ll talk more. But, for now, Rani and Andy, congratulations. Continued success with Aqua and we’ll talk to you later.

    Feit: Thanks, Alan. Buh-bye, Alan.

    Shimel: All right, guys. This is Alan Shimel for devopsy.kinsta.cloud, Container Journal, and Security Boulevard, with our friends from Aqua Security on their recently-announced $62 million raise of round C. Till next time, bye bye.

    Osnat: Bye.

    Feit: Bye.

    — Alan Shimel

  • Pivotal Software Previews Automation Framework

    Pivotal Software Previews Automation Framework

    At the North America Cloud Foundry Summit 2019 conference, Pivotal Software announced it is beta testing an automation framework that promises to keep its distribution of the platform-as-a-service (PaaS) environment continuously updated.

    In addition, Pivotal revealed it will be adding support for open source technologies including Envoy load balancing and Istio service mesh software developed outside the auspices of the Cloud Foundry Foundation (CFF) to its Pivotal Cloud Foundry (PCF) distribution. Envoy and Istio are being employed to add a new routing tier to tier to PCF to give developers more control over network traffic.

    Richard Seroter, vice president of product for Pivotal, said Platform Automation for PCF consists of a series of building block modules that will be applied to all the components of PCF as well as eventually the distribution of Kubernetes that Pivotal curates in collaboration with sister company VMware.

    Pivotal also announced that Pivotal Application Service (PAS), the runtime for PCF, will soon support Windows Server 2019 along with the ability to configure multiple custom ports per PAS container to make deploying containerized applications in a PaaS environment more efficient from a networking perspective.

    Finally, Pivotal is adding more descriptive metadata to the application programming interfaces (API) it exposes across the PAS runtime.

    Seroter said Pivotal continues to focus on automating as much of the IT operations pipeline as possible. Rather than allocating IT staff to create and manage these pipelines, Pivotal is making a case for relying on a set of managed services that span instances of Cloud Foundry and Kubernetes running on top of virtual machines deployed on either a public cloud or on-premises. That approach relies on a highly opinionated operational pipeline defined by Pivotal that IT organizations will need to adopt to benefit from a highly consistent and repeatable approach to managing IT operations at scale, he said.

    The need for a more structured approach to managing IT operations is only becoming more acute as organizations embrace Kubernetes platforms alongside Kubernetes, Seroter added. In fact, a survey of 501 IT leaders published by the CFF finds almost half of respondents (48%) report using some combination of PaaS, containers and serverless technologies together.

    It’s still unclear how much IT organizations will standardize on a particular application development platform. PaaS environments typically have a more robust set of application development tools, but they can consume tens of virtual machines to stand up. Development tools for Kubernetes platforms are still evolving, but the platform provides a more efficient way to consume both virtual machines and bare-metal servers. It is apparent that for some time to come that many IT organizations will find themselves managing multiple platforms. The challenge that creates for DevOps teams is finding a way to manage those platforms consistently using a common framework rather than having to deploy and master separate management. It may take quite a while for IT leaders to rationalize their management platforms, but with each passing day it becomes clearer that goal increasingly is within reach.

    — Mike Vizard

  • Comparing Nuclio and AWS Lambda

    Comparing Nuclio and AWS Lambda

    With serverless, you delegate the responsibility of running your infrastructure to a platform provider as much as possible. This frees your engineers to focus on building what your customers want from you—the features that differentiate your business from your competitors’. For this philosophy to work, however, the platform needs to not only give you the tools to build those features, but also deliver the performance that will keep engineers satisfied.

    Yes, services such as AWS Lambda are powerful, but they have a number of well-documented limitations that make them unsuitable for some workloads. These include:

    • Cold starts and high latency make them unsuitable for real-time applications that require consistent and millisecond-level response times.
    • The pay-per-invocation model makes them costly in high throughput scenarios.
    • The event-driven model, coupled with a max execution time or data size restrictions, makes them unsuitable for long-running tasks or heavy data or AI processing.
    • They are limited to triggers and event sources that are specific to the cloud provider.

    Enter Nuclio, an open source serverless platform that is built on top of Kubernetes and comes in both managed platform-as-a-service (PaaS) and self-hosted flavors. In this post, we will compare Nuclio with AWS Lambda, see how Nuclio addresses the above limitations and explore the new use cases Nuclio is unlocking, such as:

    • High throughput data processing pipelines or ETL.
    • Serving machine learning models in real time.
    • Real-time applications such as multiplayer games.
    • Long-running jobs and services.

    Nuclio vs. AWS Lambda

    Concurrency

    One of the biggest shifts from traditional application development to AWS Lambda is how concurrency is managed. An Express.js web application running in a container/VM can handle multiple requests concurrently. In other words, your application manages its own concurrency. You scale the application by increasing the number of concurrent requests it can handle (scaling up) and then increasing the number of containers (scaling out).

    Figure 1: Traditional applications scale up the currency within the application, then scale out the number of nodes running the application.

    With AWS Lambda, concurrency is managed by the platform, and a concurrent execution would process only one request at a time—much like an actor in the actor model, which would process one message at a time. The application can scale out by increasing the number of concurrent executions of the function.

    Lambda’s concurrency model has its advantages:

    • It simplifies application development. Concurrency is a constant source of bugs and performance issues, as developers struggle with writing highly concurrent applications.
    • It allows you to price each invocation individually because you don’t have resource contention from handling concurrent requests. This enables the pay-per-use pricing model and is one of the cornerstones of findev.

    Still, Lambda also has some disadvantages:

    • You can’t make use of idle CPU cycles when a function is waiting on IO. Since most functions are IO-heavy, this results in significant inefficiencies.
    • It requires more scaling, which means more cold starts. To handle X concurrent requests, you need X concurrent executions, which equates to X cold starts. This makes it nearly impossible to achieve predictable performance.

    Nuclio, on the other hand, can scale up as well as out. A function processor (analogous to a container) can host multiple function workers. Each worker is then able to process one message at a time. This system supports concurrency within the same processor, and then autoscales the number of replicas of the processor based on load.

    Figure 2: The architecture of a Nuclio function.

    Another interesting difference between Lambda and Nuclio is that Nuclio lets you specify both the minimum and maximum number of replicas. And as an aside, Nuclio also supports GPUs.

    Figure 3: Nuclio lets you configure both the minimum and maximum number of replicas.

    With Lambda, you can configure a reserved concurrency for a function, which (counterintuitively) sets its max concurrent executions. But there is no way to tell the system to always keep a certain number of concurrent executions running at all times. The system always scales to zero when there is no traffic—behavior that is highly undesirable for systems that experience regular spikes in traffic.

    For example, my employer, DAZN, is in the sports streaming business. We see huge spikes in traffic all the time, as millions of users flood in seconds before a sporting event starts.

    Figure 4: Sports streaming platforms, such as DAZN, experience huge spikes in traffic just before a sporting event kicks off.

    Without the ability to configure the minimum number of concurrent executions, these spikes result in large numbers of cold starts. Also, in these cases, Lambda has to scale out the number of concurrent executions quickly to meet the surge in demand. Here, we also run into the 500/minute limit on how quickly Lambda is able to scale out. As such, we are currently not able to use Lambda on the critical path of our system, which has to shoulder these spikes.

    With Nuclio, you can programmatically update the minimum replica count prior to the event so that when the spikes come, you don’t have to worry about hitting scaling limits or enduring the performance hit from cold starts. You can also tell Nuclio to scale to zero immediately via API calls, which saves resources.

    Figure 5: Adjusting the minimum number of replicas enables you to deal with predictable spikes in traffic.

    Timeout

    Another major difference between Lambda and Nuclio is how timeout is handled. With Lambda, an invocation can run for up to 15 minutes. While it’s possible for you to use recursive functions or step functions to extend this limit, both approaches have their own problems. As such, Lambda functions are great for event-driven architectures and performing short, ephemeral tasks.

    With Nuclio, there is no max execution time. The containers can keep on running, which in turn allows you to go beyond the constraints of the event-driven model. You can now turn a function into a long-running service, which unlocks some interesting use cases such as long-running ETL jobs and training machine learning (ML) models.

    Caching State Between Invocations

    Both Lambda and Nuclio functions accept an event and context during an invocation.

    Figure 6: Both Nuclio and Lambda functions accept an invocation event and context as arguments.

    With Lambda, the context object is ephemeral and does not persist between invocations. If you want to persist data between invocations (e.g. static configurations, database connections), then you need to declare them as global variables outside of the function handler.

    With Nuclio, the execution context itself is persisted between invocations and can be used to cache state. The context object also includes a built-in logger, which supports structured logging with JSON and four log levels: DEBUG, INFO, WARN and ERROR.

    You can configure the default log level for a function and can even override this default log level per invocation—which is very useful for debugging. You also have the ability to export your logs to external services such as Elasticsearch.

    Figure 7: With Nuclio, you can select the default log level for every function.
    Figure 8: You can also override the default log level for an invocation.

    In addition, there are hooks for performing context initialization, which is called before the first invocation on the function. This allows you to perform initialization logic before the container is put into active use and removes the dreaded cold start problem that Lambda suffers from.

    Data Volumes and Persistent Data Connections

    With Lambda, functions only run when they are triggered by events. Furthermore, concurrent executions are garbage-collected when they have been idle for a few minutes. This behavior makes life difficult when you are working with relational database management systems (RDBMS) and other systems that require persistent connections. Indeed, a set of guidelines has been developed to help you avoid the many pitfalls of using Lambda with RDBMS. Furthermore, Lambda doesn’t allow you to use persistent data in standard file system mounts, which forces you to copy to/from object storage before working on large files such as images, logs, ML models, etc.

    With Nuclio, however, you can use the context object to maintain persistent connections to databases. Since the context is maintained at the processor level, you get better reuse, as they are shared across invocations. You can also take care of other aspects of data-fetching with data bindings, including batching and caching, which helps improve IO performance of the application. Additionally, you can mount volumes to functions, which is useful for working with ML models or Tensorflow, and you can mount Kubernetes secrets as volumes. Indeed, Nuclio supports all of the volume types that Kubernetes supports.

    Runtimes

    Both Lambda and Nuclio support popular languages such as Go, Node.js, Python, .Net Core, Java and Ruby. Also, both platforms offer a way for you to customize the execution runtime.

    With Lambda, you can create a custom runtime and distribute it through AWS Lambda Layers. This lets you introduce additional language runtimes that are not natively supported by the Lambda platform. Several vendors have published runtimes for PHP, Rust, Erlang and Elixir, to name a few.

    With Nuclio, you can run functions on your own Docker image (see Figure 9), which can come from a private image repository. This allows you to tailor the execution environment itself.

    You can also support additional language runtimes through a Shell function, which allows you to handle invocation events with any executable binary. See this example for more details.

    Figure 9: Nuclio lets you run functions on top of your own Docker image, which can come from a private image repository.

    Triggers

    Lambda is supported by a wide range of event sources.

    Nuclio ships with 13 triggers, including cron, HTTP, Kafka, Kinesis and RabbitMQ. Since Nuclio is open source, you can also write your own trigger for services that you want to integrate with and leverage other people’s contributions. The HTTP trigger gives you an easy way to integrate Nuclio with other event sources that support HTTP as target, such as SNS. Also, since Nuclio supports the CNCF CloudEvents standard, it can arguably support many more event sources that are CloudEvents-compliant.

    Nuclio triggers are all normalized to the same Event object. This removes the need to understand the specific event signature for each event source, which is often confusing when working with Lambda. It also makes it easy to switch a function between different triggers.

    Built-In HTTP Trigger

    With Lambda, you need to use API Gateway to create an HTTP endpoint for your functions. API Gateway is a feature-rich service, but it’s also complicated and often costs more to run than the Lambda invocations themselves. It also adds another source of latency to your API, which, at the minimum, is around 5ms to 10ms, and it can overhead spike to more than 100ms. This cost and latency overhead make it unsuitable for applications with high throughput or hard real-time requirements.

    With Nuclio, every function gets a private HTTP interface by default. To expose the endpoint publicly, you need to specify an HTTP trigger similar to API Gateway. However, unlike API Gateway, this HTTP trigger does not incur extra costs and has minimal latency overhead.

    Figure 10: With Nuclio, every function gets a private HTTP interface by default.

    Unlocking New Use Cases with Nuclio

    As you can see from our comparison, Nuclio differs from Lambda in a number of important areas, such as its concurrency model and that it has no max execution time. This opens the door to a whole range of use cases. Let’s take a moment to look at a few.

    High-Throughput Data Processing Pipelines or APIs

    For a high-throughput API, the cost of both API Gateway and Lambda is drastically higher than an equivalent application running in containers. This cost discrepancy has lead many to rewrite their applications.

    Nuclio’s concurrency model makes more efficient use of available resources, which significantly reduces operational cost when running at scale. Functions have built-in HTTP interfaces so you also don’t need to pay for an expensive API Gateway service.

    The ability to mount a volume to your function also lets you read and write data to/from a mounted volume at high speed and enables building stateful applications. Again, you can’t do this with Lambda today, as it doesn’t allow you to attach Amazon Elastic File System (Amazon EFS) volumes to functions.

    These features make it economically feasible to run high-throughput and high-performance APIs on Nuclio functions. The same can also be said about high-throughput data processing pipelines that have to process multiple terabytes of data per hour.

    APIs with Predictable Spikes in Traffic

    Nuclio gives you the ability to configure a minimum number of replicas. This allows systems that experience predictable spikes in traffic to reserve sufficient resources ahead of time and avoid degrading the user experience when the spikes happen. Examples include food ordering services such as Just Eat or Deliveroo or sports streaming services such as DAZN.

    At the same time, Nuclio still lets you scale to zero by setting the minimum number of replicas to zero. It gives you the control to optimize for resource usage or latency, depending on the situation.

    Real-Time Applications

    Nuclio does not suffer from cold starts and is able to deliver consistent and sub-millisecond response times on invocations. This makes it a suitable solution for applications with a hard, real-time requirement such as multiplayer games and real-time bots.

    Serving Machine Learning Models in Real Time

    To serve ML models in real time, you need to have both strong and predictable API latency and the ability to load and work with ML models that often are large in size (GBs).

    Nuclio lets you attach Kubernetes volumes to your functions, and there are no size limits on these volumes. Combined with the performance characteristics, it’s possible to implement these demanding workloads with Nuclio functions.

    Nuclio also has native integration with Jupyter, and lets you automatically deploy Jupyter notebooks and ML models as Nuclio functions.

    Long-Running Jobs and Services

    Nuclio does not impose a max execution timeout on function invocations. This allows you to turn your functions into long-running services and perform long-running ETL jobs.

    Nuclio’s init_context() hook lets you create long-running services, such as an application that constantly reads off a Twitter feed (e.g. loads the TwythonStreamer with the context, which is polling an external service, versus becoming triggered by an event).

    Conclusion

    As we discussed, Nuclio is one of the few open source solutions that are also business-viable. It has key architectural advantages for higher performance or data-driven applications, including:

    • Nuclio is cloud-agnostic. It can be used in multi-cloud/hybrid-cloud scenarios. You can also run Nuclio on a laptop using plain Docker, which makes debugging easier.
    • Nuclio’s concurrency model and the ability to mount file volumes lets you build high-performance APIs and high-throughput data processing pipelines.
    • Nuclio gives you greater control over the concurrency of your application, which makes it viable even for applications with very spiky traffic.
    • Nuclio’s execution contexts are persisted between invocations, and it doesn’t impose a max execution time on invocations. This allows you to create long-running stateful applications such as ETL jobs.
    • Nuclio lets you attach Kubernetes volumes to your functions and has no limitations on the size of the volume. This makes it possible for you to work with large ML models that often are GBs in size. Nuclio also has native integration with Jupyter and can automatically deploy your Jupyter notebooks and models as functions.
    • Nuclio provides a good out-of-the-box developer experience. It has a built-in logger with structured logging support, and you can easily export your logs to an external log aggregation service.

    If you are looking for a serverless platform that is not tied to a specific cloud provider, Nuclio is worth a look.

    — Yan Cui

  • DevOps Chat: Serverless and Abstraction with Nimbella’s Anshu Agarwal

    DevOps Chat: Serverless and Abstraction with Nimbella’s Anshu Agarwal

    Anshu Agarwal has a tremendous record of working in startups that had successful exits. Now for the first time, along with her co-founders, she is actually founding the startup herself. Nimbella is a serverless platform that is cloud-agnostic and makes developing and deploying applications easy. Whether in a public cloud, private data center or both, Nimbella can help.

    In this DevOps Chat, we speak with Anshu about her own personal journey and where Nimbella is and what the plans are for going forward.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Alan Shimel: Hello, everyone, it’s Alan Shimel of devopsy.kinsta.cloud and you’re listening to another DevOps Chat. Today’s chat actually features a company that’s just starting out here, but it’s a guest who’s had a rather long career in the tech space. As long as mine, even, at some point, but I’m sure I’m much older. Anyway, I’d like to introduce you to Anshu Agarwal. And, Anshu, if I messed up your last name, I apologize. Was that good?

    Anshu Agarwal: Thank you, Alan. You said it perfectly right. Thank you for having me today.

    Shimel: Thank you. So, Anshu, let’s start off – I referenced that you’d been in tech a while. Let’s give people an idea of your personal journey that brings you here today, even going back to Speedera and beyond, if you’d like, but if you wanna start with Speedera, that’s fine. But let’s give folks an idea of who you are, what your background is.

    Agarwal: Sure. Thank you. So I am an engineer by background and I moved into product management and marketing after I finished my MBA. And, after that, I joined a startup and then the startup bug never left me. So I joined Speedera, which got acquired by Akamai. Then I joined another startup, Ankeena, which got acquired by Juniper. Another startup, ConteXtream, got acquired by HP. And my most recent startup, Cedexis got acquired by Citrix, so I have been acquired four times. And, in all of those companies, I kind of delivered the success for other people’s ideas because they were all successful startups, got acquired by very, very large companies, so they were indeed – from value standards, they’re considered successful, but, for myself, I had never really done a company of my own.

    So, when I got the opportunity of just starting and being a founder of a cloud infrastructure, because that’s my background – I’ve been doing cloud infrastructure for last 15 to 20 years – there was no question that I wouldn’t do it. And we got started on this company – the company name is “Nimbella.” And it is in the serverless framework or serverless platform space. And we are kind of disrupting what serverless is, so – or we are providing what serverless promises to the developers. So that’s what we are working on now.

    Shimel: Excellent. You know, you’re way too modest and humble because, for many people listening, whether they’re in the valley or Boulder or Austin or New York or Boston or London or Bangalore or anywhere else in this world, having four startups that were acquired by companies like Akamai, HP, Citrix, and I forgot the fourth one – I apologize – a lot of people would call that a career. Right? I mean, whether they founded the companies or not, just being associated with four companies that had successful exits to large companies like that is something to be proud of and it speaks volumes as to either you’re really, really lucky or you’re doing something right. Right? So congratulations to you for that.

    So you’ve mentioned Nimbella and I wanna kind of share with our audience up front that Nimbella is – you have raised some funds for the company and there’s a great startup – there’s a great founders group involved. You mentioned, I think, one of your cohorts from Speedera; I think there’s two other founders in the group. But the company’s sorta still – I don’t wanna say stealth, but pre-product, let’s call it. Pre-public-product. So I don’t wanna put you on the spot. I’d rather talk, I think, if it’s okay, Anshu, about some of the problems you see and potential solutions that we see.

    You know, we live in a great time for developers and engineers. Internet time, right? We’ve gone from servers to hypervisors to containers. Now serverless. And serverless seems to be all the rage, but, like any new technology, it’s not birthed mature, right? It doesn’t come out mature; it doesn’t start mature. And so there’s gonna be growing pains. Can you share with our audience a little bit about what you see as some of the growing pains around serverless or what you’re hearing from people around that?

    Agarwal: Absolutely. Well, thank you for – this is a great question because it is definitely the best thing that’s happening for developers. The reason I say that is because what developers really want is to develop their business logic or develop the code and not worry about the infrastructure. And serverless promise is all about that, that you don’t have to worry about the infrastructure. You don’t ever have to worry about how it scales, how it is secured. Anything that requires the knowledge of infrastructure should not be a developer’s worry.

    But, in today’s serverless frameworks – and there are a few serverless frameworks and some are very popular ones – there is so much complexity still for the developers because they have to combine many services. And, for instance, they have to think about storage, they have to think about identity management, and they have to learn all these services and integrate. Not only that, the management and debugging is still an issue. And these are growing pains, as you mentioned. The serverless computing is still in a nascent stage and, therefore, it’s lacking all the abstractions that are needed for the adoption to accelerate into new markets and application domains.

    Not only that, serverless today, if you look at it, is used only for stateless applications, so you’ll see it in IoT applications, you’ll see it in reactive kind of applications only. It is not suited for long-running or stateful workloads. The reason being is because serverless today is serverless compute; it is not serverless storage. So that’s another problem. We may consider it as a problem or we may consider it as the limited adoption of the technology, but that’s something we have to address if we want this to be adopted in general, across all workloads. Then the –

    Shimel: I’m sorry. We may also consider it as an opportunity, right? I mean –

    Agarwal: Oh, absolutely.

    Shimel: Yeah.

    Agarwal: Absolutely. And that’s what we’re doing. And I’m gonna talk about Nimbella and how Nimbella is addressing it.

    Shimel: Mm-hmm.

    Agarwal: Another important aspect of serverless today is, like any new technology environment, there is serious vendor lock-in because, if you are using AWS’s Lambda serverless framework, you are programming to the nuts and bolts of Lambda. If you are using Google, you are programming to GCP, and so it is with Microsoft Azure. So, in a sense, you are programming to proprietary frameworks and, therefore, your code is not cloud-portable.

    So, tomorrow, if your company decides that, “Now we are going to move from AWS to Google,” you gotta rewrite the whole thing again. So that is actually, again, the serverless promise, and, therefore, vendor lock-in is very real, especially for the companies, actually, that choose not to go to public cloud because they’re part of regulated industry or whatever _____. They want something to be running in their own private cloud; these serverless frameworks are not an option for them. And then, say, you were able to write code for all different frameworks, but then the complexity of operations is there because you can’t monitor and observe at each level since these are proprietary frameworks across these clouds.

    So there are serious issues for widespread adoption and that’s where we come in. That’s the opportunity we looked at when we decided to create this company, is we want to create a platform, a framework, that is providing all the necessary abstractions so the developer is not to worry about how the infrastructure works, how to scale the code, how to secure the code. The code is just nebulous logic that they write. Then it is also suited for long-running, stateful, streaming workloads, such as AI/ML workloads. I mean, we have a greater adoption of AI happening in every industry. If we are not going to be able to handle AI workloads, we are missing a big market.

    And those are real, real problems and we are addressing it with Nimbella, you know, the technical problems. Then there are operational issues where you want cloud portability, so we are also addressing that part because we are providing a layer of abstraction and it’s open-core-based, so a developer can program the way they program the business logic and not worry about which cloud they’re writing.

    Shimel: Got it. Got it, got it, got it. So, again, I don’t wanna be uncomfortable or make you uncomfortable with what we’re gonna talk about, but, you know, I was at KubeCon out in Seattle last month – seems like a year ago, but it was only last month – and, surprisingly or not surprisingly, “serverless” seemed to be on everyone’s lips. Right? And maybe some people listening to this are saying, “Wait a second, Kubernetes is for containers and containers can run on bare metal, yeah, but they run on VMware or hypervisor as well.” What do you think the role of Kubernetes is in the serverless future? Fair?

    Agarwal: Kubernetes is a great technology. I really think it has great future. And serverless frameworks use Kubernetes or something else like that. And we were also at KubeCon. It was actually our first conference as an Nimbella person attending – one of my cofounders, who actually is the creator of OpenWhisk Apache, a serverless framework, he attended it. And he mentioned the same thing that you mentioned, that serverless was on everybody’s slide deck. Okay? It is something everybody is looking at; it is something everybody is kind of they have it on their roadmap, that they wanna work on it. They wanna look at it and see if it works for their environment.

    And Kubernetes is perfect, actually. It provides the platform needed because it is widely accepted these days and it provides the necessary environment, but, again, it should not be the burden of a developer to know how to run, work with Kubernetes. It should be the infrastructure serverless framework that provides that to the developer and the developer’s still only programming the logic. It’s not for the developer to worry on what environment, what container environment they are working on and what VMs are being used and what bare metal is being used. That’s all abstracted away for the developer.

    Shimel: Got it. Got it, got it, got it. So, you know, I’m sure there are people listening to us today who are thinking to themselves, “This woman has been in four startups and has had tremendous success.” And now I’m sure you’re a CEO, right, of Nimbella and you’re cofounder –

    Agarwal: That is correct.

    Shimel: Right? And I’m hoping there’s a whole bunch of women engineers out here or women entrepreneurs who are listening to you, saying, “Hey, if she can do it, I can do it.” And we don’t have a lot of time left, but I wanna address those folks there, that are near and dear to me for a lot of reasons. What’s your advice to them?

    Agarwal: Absolutely. If I can do it, they can do it. That is a very true statement. And, I mean, you said some great words about me, but I consider myself average successful person and, yes, I have been lucky that the four companies I’ve worked for had great exits. But being a founder and CEO is still very different from what I did for the other companies before. So, basically, when you are part of the company, other companies, you’re not bothered by operational aspects of the company. You’re not bothered by hiring for every possible function in the company. So the skill sets that I’m developing now, there is no other experience that could have taught me that, so, even though – I say, “Everybody can do it and anybody can do it,” but they still have to learn the art of running a company on the job. It just – there is no course. There is no education that can be given because you have to experience it.

    So, to all the women engineers that are listening, I would say, “If I can do it, you can do it. You just have to just get into it. You just have to dive into it and it will come to you. You will develop your advisors. You will develop the people who help you on the way because you won’t have all the skill sets, but you will know who to go to for what skill set, as you take that role.”

    Shimel: Absolutely. Absolutely. And, you know, women or not women, entrepreneurs – I’ve also founded and helped start my fair share of companies – I don’t know if it’s courage or just pure moxie, if you will, right? You just put one foot in front of the other, right, and you just keep moving forward. And you can’t boil the ocean, right, but you can – these things are incremental, right, and they’re evolutionary. They’re not _____ –

    Agarwal: Absolutely. You’re absolutely right. These are such an incremental thing and you may be not finding the best solution, but you are optimizing your solution, at every step, because you’re trying to handle so many things and, if you wait for the best solution to arrive, it may be too late. So you’re kind of optimizing the solution for whatever issue or whatever problem you’re handling, and you move on with that. And it’s just only time will tell how successful I am in the role, but this is my experience six months into this company, six or seven months into this company, and I’m still learning the art.

    Shimel: Absolutely, it is. So what do you – short-term future, where can we find out more on Nimbella or when will we find out more, do you think?

    Agarwal: Oh, absolutely. So there is some information on the website – very little information, I would say – but it gives you a flavor of what we are doing. Then, in Q1, this quarter, we are going to be releasing our developer playground, which is actually – because the buyer of serverless technology is the developer and developer experience is the most important thing, a developer has to feel one with the programming experience. And that’s the true serverless promise and we wanna deliver on that promise, so, in Q1, we are going to release that.

    And, in later quarter, in Q2, since I have mentioned private cloud and hybrid cloud, there will be offering for private cloud in Q2. So, as this quarter progresses, we are going to populate the website more with the content and we’re going to host more meetings like this and make it available to the developer community in general, our solution, and then, later on, for enterprise sites.

    Shimel: Great. Great, great, great. Anshu, when I started, I said, “These are only about 15 minutes. It’s gonna go so quick, you won’t believe it.” If I told you we’re closer to 20 minutes already, you’d probably say, “Oh, my,” but we are and we’re gonna need to call an end to this DevOps Chat. You know what? It sounds like there’s a lot going on here and, if we can have you back on, you know –

    Agarwal: Oh, that would be great, Alan. I really hope we can –

    Shimel: Yeah?

    Agarwal: I really hope we can get back when we have our developer playground because I’d love to talk more about it.

    Shimel: I promise you we will.

    Agarwal: Thank you.

    Shimel: Promise you we will. Thank you. Anshu Agarwal, founder/CEO of Nimbella, our guest here on this DevOps Chat. This is Alan Shimel and you’ve just listened to another chat.

    — Alan Shimel