devopsy.kinsta.cloud

Tag: serverless

Python Benefiting From Increase in DevOps Use

DevOps and Python have developed a mutually beneficial relationship.

In a recent survey released by the Python Software Foundation and software development company JetBrains, researchers found that more and more developers are using the program language for an array of versatile projects, including DevOps and machine learning.

In fact, Python developers told the researchers that DevOps is increasingly part of their professional development work.

“In 2018 we had significantly more respondents specifying they’re involved in DevOps (an increase of 8 percent compared to 2017). In terms of Python users using Python as their secondary language, DevOps has overtaken web development,” according to the “2018 Python Developers study,” which is based on responses from 18,000 developers in 150 countries.

Over the last two years, Python has grown more important to developers thanks to its flexibility, especially when it comes to web development. It’s no surprise that as other projects have gained popularity in the enterprise—DevOps and machine learning—developers have started adopting the language to other disciplines, especially as businesses invest more in application development.

In TIOBE’s February 2019 index, Python now ranks third behind favorites such as Java and C, edging out C++ for its current position.

Digging into the numbers, the survey finds that 43 percent of developers are using Python for DevOps projects, as well as system administration and writing automation scripts. That’s an increase from the 35 percent who reported the same types of uses for the programming language in 2017.

The report notes that these numbers reflect a combination of Python used as either the primary or secondary language for various projects. As the report notes: “DevOps/system administration/writing automation scripts has moved into first place among Python users using it as a secondary language.”

Machine learning is another up-and-coming category, with 38 percent of developers using Python for these projects compared to 31 percent last year.

Overall, data analysis remains the No. 1 use case for Python developers, with 58 percent reporting that it’s their main focus when it comes to development.

In second place is web development, according to the report.

In terms of the top cloud platforms for Python developers, Amazon Web Service is the top choice, with 36 percent of respondents reporting that they use AWS. From there, it’s Google Cloud Platform (29 percent) Heroku (26 percent), DigitalOcean (23 percent) and Microsoft Azure (16 percent).

About a third of those surveyed responded that they don’t use any cloud platforms.

When asked about running code in a cloud production environment, 47 percent responded that they use virtual machines, although 40 percent of Python developers reported that they prefer containers. Another 28 percent use platform as a service (PaaS) and 21 percent are taking the leap to serverless computing.

Additionally, when developing for the cloud, about 35 percent of those in the survey report that they use Docker containers.

This increase use of Python within DevOps, as well as other connected areas such as serverless computing, does not surprise Anshu Agarwal, the CEO and co-founder of Nimbella, a cloud-agnostic, serverless cloud platform for developers. She noted the language’s use within a wide range of projects, specifically machine learning and AI, are driving this change.

“Python developers are driving serverless requirements in new and unique ways, primarily because of the interest in data analysis, ML and AI,” Agarwal wrote in an email. “These data analysis and ML/AI-centric serverless use cases are different than request/response style serverless functions which run for much shorter durations. Python functions in serverless may have much longer durations (10s of minutes or hours), and consume a lot more memory. For such functions a different kind of serverless framework needs to be adopted that can handle long running workloads.”

When it comes to continuous integration systems, about a third of respondents don’t use any. However, when they do, Jenkins is the most popular at 25 percent, followed by Gitlab CI and Travis CI, with 18 percent each. For configuration management, 20 percent reported using Ansible, while 9 percent used custom tools. Puppet, Salt and Chef also appeared in the list.

Finally, about two-thirds of Python developers (69 percent) use Linux as their main operating system of choice for development. Microsoft Windows comes in a distant second at 47 percent and Apple’s macOS in third at 32 percent, according to the study.

— Scott Ferguson

February 14, 2019
The Limiting Factors of Microservices Also Apply to FaaS

In enterprise development and deployment, the pattern is easy to detect. A big monolithic application is targeted for re-architecting as a microservices architecture. People excited about microservices get together and break up the design to make it far less monolithic and far more loosely coupled.

If your organization is lucky, it is at this stage that those responsible realize that breaking a monolithic application down too far is bad for complexity, performance, monitoring and maintenance—pretty much everything re-architecting is supposed to fix.

Far too many organizations don’t realize this until the implementation phase, though. First, a metric ton of little tiny microservices are deployed, then the organization realizes that functionality such as database access can be applied much more efficiently through one larger service that handles all interaction with the database for the app, rather than through five or 10 smaller services that replicate code and end up calling each other anyway.

Function as a service (FaaS) has much the same issue. It is an astounding solution for some uses, but in the end, users must consider what access the function requires to other parts of the system and what task is being achieved. The early uses of FaaS are well-documented; longer running independent jobs such as image or video processing were a bit early hit, for example, particularly for services that have highly varying traffic rates. But other uses, such as handling bottlenecks in traffic spikes (hello holiday shopping season!) or out-of-band operations processing, are less documented at this point. Entire applications have been designed from the ground up in serverless, but they are relatively few in terms of overall applications out there.

FaaS is highly suited to DevOps, because upgrading the function is as simple as redeploying code. There are no concerns about OS or library version, because those are largely beyond your control. But that is as big a negative as it is a positive. There is no flexibility in OS version or library inclusion because those are beyond your control—for the most part, anyway.

As with the vast majority of new technologies, expect adoption of serverless to grow and the hype to grow more quickly. It is definitely in the market where we have seen massive shifts—virtualization and then containers really did live up to the hype in terms of usage—but it needs to have a driving reason for adoption. Look closely at what your application and its DevOps toolchain are doing before hopping into the deep end. For some uses, FaaS is the fastest/easiest/lowest-maintenance solution. But that does not make it the Swiss army knife that virtualization and containers have proven to be. Indeed, if you think persistent storage is painful under containers, try it in a FaaS environment—as just one example.

FaaS is useful in many scenarios, but just remember where/when/why you are adding FaaS into your DevOps processes, and take advantage of on-demand processing with few scaling limitations while avoiding seeing everything as a FaaS problem because FaaS is the FaD.

— Don Macvittie

December 21, 2018
Protego Spearheads Launch of the OWASP Official Serverless Top 10 Project

Report to Educate Application Security Practitioners on Serverless Application Risks and Mitigation Techniques

Baltimore, Maryland – The Open Web Application Security Project (OWASP) released today the official OWASP Serverless Top 10 project initiated by Protego Labs. The project launch begins with a provisional report designed to be a first look into the leading risks in serverless security and to serve as a baseline for official OWASP Serverless Top 10.

The OWASP Top 10 is the de-facto guide for application security practitioners to understand the most common application attacks and risks. Its data spans vulnerabilities gathered from hundreds of organizations and over 100,000 real-world applications and APIs. The Top 10 items are selected and prioritized according to this data, in combination with consensus estimates of exploitability, detectability, and impact into providing The Ten Most Critical Web Application Security Risks.

“Since serverless applications are vastly different, security risks have changed,” said Tal Melamed, project leader. “With serverless, hackers must try different vectors and approaches for attacks; developers cannot employ traditional perimeter protections and need to change their way of thinking, as almost none of the mitigations suggested for traditional applications would fit in the serverless world, which is why we’re working on the OWASP serverless Top 10 project.”

Similar to the OWASP Top 10, the final Serverless Top 10 will be based on data collected from real industry input through an open call. The OWASP Serverless Top 10 is the first and only OWASP report that examines the main risks in serverless security. It also serves as a baseline for creating the official OWASP Serverless Top 10 security risks to educate organizations about the unique security landscape of serverless applications.

Protego is backed by a group of security industry investors, including Ron Gula of Gula Tech Adventures, Glilot Capital Partners, and former RSA CTO, Tim Belcher. Earlier this year, Protego won the Startup Competition for the most innovative cyber initiative at the Cybertech Tel Aviv 2018 Conference. Additionally, Protego is currently nominated for Best Cybersecurity Startup in the Cyber Excellence Awards, and was listed as a 2019 company to watch by SD Times.

About Protego

Recognizing the inadequacy of traditional application security paradigms, Protego Labs designed the first comprehensive solution built with the unique constraints and opportunities of serverless in mind. Through continuous serverless security posture, dynamic serverless intelligence, and elastic defense, Protego helps organizations achieve control over the security of their applications. For more information, visit http://www.protego.io.

About OWASP

OWASP is a worldwide free and open community focused on improving the security of application software. There are over 200 OWASP Local Chapters world-wide that are free and open to anyone to attend. OWASP tools and documents can be used to detect and to guard against security-related design and implementation flaws, as well as to add security-related activities into your Software Development Life Cycle (SDLC). For additional detail about OWASP, leadership, and corporate details, visit https://www.owasp.org.

November 19, 2018
Fission Open Source Serverless Framework Offers Live-Reload, Canary Deployments, Record-Replay, More Features to Improve the Quality and Simplify Release Automation of Serverless Applications on Kubernetes

Live-reload, Record-replay, Automated Canary Deployments, Prometheus integration, and more give both Dev and Ops confidence in the production-readiness of serverless applications, as well as easy troubleshooting, and cost/performance optimization

Sunnyvale, CA – October 16, 2018 – Platform9 (https://platform9.com/), the leader in SaaS-managed hybrid cloud, today announced a new release of Fission.io – the popular open source, Kubernetes-native Serverless framework – with new features enabling developers and IT Operations to improve the quality and reliability of serverless applications.

Fission is the industry’s first serverless solution to offer built-in Live-reload and Record-replay capabilities to simplify testing and accelerate feedback loops. Other new features include Automated Canary Deployments to reduce the risk of failed releases, Prometheus integration for automated monitoring and alerts, and fine-grained cost and performance optimization capabilities. With this latest release, Fission offers the most complete set of features to allow Dev and Ops teams to safely adopt Serverless and benefit from the speed, cost savings and scalability of this cloud native development pattern on any environment – either in the public cloud or on-premises.

Learn more about Fission, the open source, Kubernetes-native Serverless Framework at: (https://fission.io/).

“Fission was created to provide a simpler, easier way for developers to accelerate time to value with Kubernetes. Our goal is to help developers produce quality serverless code, and provide Ops teams with the utmost confidence to run serverless applications in production,” said Soam Vasani, Creator of Fission at Platform9. “Serverless allows developers to move faster and be more productive. The latest release of Fission focuses on accelerating feedback loops and lowering deployment risk, to ensure that teams can not only move fast, but also safely, and at scale.”

The latest feature set of Fission includes:

Live-reload: Test as you type

With Live-reload, Fission automatically deploys the code as it is written into a live Kubernetes test cluster, and allows developers to toggle between their development environment and the runtime of the function, to rapidly iterate through their coding and testing cycles.

This allows bugs to be found and fixed earlier in the application development lifecycle, when it is cheaper to do so – before they are discovered in the higher environments or cause any service disruption in Production. Further, it simplifies and increases the fidelity of integration tests, by running them earlier in the process using a live environment that’s consistent with the configuration and related services (i.e. database, API calls, etc.) that are used in Production.

Record-replay: Simplify testing and debugging

Fission is the first serverless solution that offers out-of-the-box Record-replay functionality for easy testing and troubleshooting. Record-replay automatically saves events that trigger serverless functions and allows for the replaying of these events on demand with detailed information on how the application is used, the inputs and the outputs of the functions. Fission users can configure which functions and workflows to record and for how long to retain the recorded events.

Record-replay is used by developers to reproduce complex failures during testing or debugging, simplify regression testing, and troubleshoot issues (i.e. inspecting an execution of a function based on past input). In addition, Operations teams often enable recording on a subset of live production traffic to help engineers reproduce issues or verify application updates.

Automated Canary Deployments: Reduce the risk of failed releases

Canary deployments are a proven deployment strategy to minimize the risk of failed application releases and avoid service interruptions to end users. In this strategy, the new version of the application is first deployed only to a small percentage of the live traffic, and then gets incrementally rolled out to Production once it has been established that the version is stable. In the case of Production failures, the application can be rolled back to the previous, stable version.

Fission is the first open source serverless framework to provide fully automated Canary Deployments that are easy to configure. This saves DevOps teams and Site Reliability Engineers the need to manage Canaries manually or invest in cumbersome scripting and testing to execute this advanced deployment strategy – making it intuitive, simple to use, and error-free. Ultimately this minimizes downtime risk for applications.

With Automated Canary Deployments, Fission automatically increments traffic proportions to the newer version of the function as long as it succeeds, and rolls back to the old version if the new version fails. Users can configure the percentage of traffic that will receive the new version of the function, the error rate that will constitute as failure, and the release rate at which to roll out the new version.

Prometheus Integration: Easy metrics collection and alerts

Out of the box integration with Prometheus enables automatic aggregation of function metrics, including the number of functions called, function execution time, success, failures, and more. Users can also define custom alerts for key events, such as for when a function fails or takes too long to execute. Prometheus metrics can also feed monitoring dashboards to visualize application metrics.

Cost Optimizations in Fission

Since Fission is open source and works on any Kubernetes cluster, it enables enterprises to easily run a Lambda-like Serverless service on any infrastructure – using either the cheaper instances on public clouds, or leveraging their own data centers. To allow IT to maximize infrastructure utilization on both public cloud and on-premises resources, Fission offers fine-grained cost and performance optimization controls.

Serverless functions can be configured with specific CPU and Memory resource usage limits, minimum/maximum number of instances and auto-scaling parameters. These parameters allow for functions to be tuned with an execution strategy that best fits the specific business use case. For example, functions that have severe cost constraints can be deployed into containers on-demand, minimizing costs at the expense of performance. Conversely, functions that need performance above all other requirements can be configured to have instances always running, ensuring low latency but driving up costs. Functions can also take advantage of Fission’s pre-warmed container pools, which aggregate the cost of pooling over a large number of functions, while providing the performance benefits for all of them.

“Our global photo platform helps hundreds of millions of devoted users preserve their memories by combining all of their favorite photos on thousands of customized products. We are always looking for ways to improve the way we manage the scale and quality of our applications. These new Fission features will help our developers deliver new customer experiences built on serverless applications without the dependency of managing the complexity of scale”, said Kenneth Lam, Director of Technology at Snapfish. “Fission allows our company to benefit from the speed, cost savings and scalability of a cloud-native development pattern on any environment we choose, whether it be the public cloud or on-prem.”

To install the latest version of Fission, visit: (https://fission.io).

Share This: New @fissionio features include Live-reload, Record-replay, automated #Canary deployments, #Prometheus, and more improve quality and lower the risk of #serverless application release on #Kubernetes #faas https://platform9.com/press/fission-open-source-serverless-framework-offers-live-reload-canary-deployments-record-replay-more-improve-quality-releases-automation-serverless-on-kubernetes/ @Platform9Sys

About Platform9

Platform9 (platform9.com) delivers a SaaS-managed hybrid cloud solution that turns existing infrastructure into a cloud, instantly. We help enterprises drive digital transformation by enabling them to manage VMs, Containers and Serverless Functions on ANY infrastructure — on-premises, in public clouds, or at the edge – with a self-service, simple and unified experience. Customers such as Cadence, Autodesk, Veritas, Nanometrics, EBSCO, Bitly, LogMeIn, and Aruba see upwards of 300 percent improvement in IT efficiency, 33 percent faster time to market, and 50-80 percent improvement in data center utilization and cost reduction. The company is headquartered in Sunnyvale, CA, and is backed by Redpoint Ventures, Menlo Ventures, Canvas Ventures, and HPE.

October 16, 2018
DevOps 2.0: A New Evolution of Serverless Cloud Architecture
Science teaches us to formulate hypotheses and test them experimentally to advance systematically. While this sounds logical, DevOps—and software architecture in particular—does not follow this approach because current tools make this too cumbersome. So, architecture choices are frequently made by HiPPO (highest paid person’s opinion).

However, the rate of development, especially in the serverless or function-as-a-service (FaaS) space, makes it difficult to gather all necessary information for HiPPO to work effectively. For example, according to AWS, it publishes on average two new cloud services per day, with similar development rates at other public cloud providers. With so many very nuanced choices, picking the optimal architecture without experimentally testing them is impossible.

We propose a fundamentally different approach for developing efficient and robust serverless architectures: hypothesis-driven architecture evolution, which consists of the steps deploy, evolve, measure, evaluate and iterate. In this blog post, we will go through each component and demonstrate how this can be done in an automated fashion to bring out the inner scientists in all of us.

Deploy with Code as Text

To deploy easily and consistently, the serverless architecture stack needs to be fully defined through code/text. This is widely known as infrastructure as code (IaC) and comprises the full infrastructure, from the computational core in the serverless functions all the way to permissions, databases and connecting services. Frameworks such as Serverless Framework and Terraform or vendor-specific tools such as AWS CloudFormation enable this by allowing a single file to define the infrastructure used and to automatically deploy these services. This ensures that multiple versions can be deployed in isolation even though they are hosted to the same availability zone for reducing confounding factors when comparing performance.

Evolve the IaC for Hypothesis-Driven Advancements

This infrastructure file can then be modified and re-deployed to systematically test hypotheses, such as whether an algorithm is faster or a particular autoscaling group is more efficient. This idea was proposed first by James Lewis from ThoughtWorks in the context of general software architecture development, but is particularly applicable for the serverless space.

Measure Performance of the Newly Evolved Architecture

The second key element to this novel way of evolving architecture is the automatic evaluation of any newly deployed architecture without manually recording runtime or specifying interactions between services. Here, tools such as Epsagon can help in automatically detecting the workflows in architectures and analyzing their performance.

Evaluate and Iterate

In this approach, evaluation needs to keep pace with the overall process. To be effective, it is imperative to be able to identify errors and bottlenecks across the entire architecture in a timely fashion. In serverless architectures, most tools focus on the individual function rather than a full transaction from end to end. You may be made aware of a long-running function but you have to scrape logs and go through your code to perform root cause analysis. Tools such as Honycomb or Epsagon help to collide errors across multiple layers or the entire data flow.

Case Study: Improve Runtime Performance of a Bioinformatics Tool

We now describe the two key aspects (deploy and evaluate) on a practical example showcasing how it has helped improve the runtime of a serverless application. We chose the bioinformatics software framework GT-Scan, which is used by Australia’s premier research organization to conduct medical research, to improve its runtime by 85 percent.

GT-Scan was one of the first serverless architectures (Jeff Barr Blog) with a focus on burstable web services that conducts data- and compute-intensive tasks. As such, it relies heavily on all of its components to be as time- and resource-efficient as possible.

We contrast the automated approach against a previous approach in which the performance was evaluated using AWS X-Ray (AWS Public Sector Blog) and summarize our three learning outcomes:

Visualizing the Current Architecture Automatically is Important

Key to rapid architecture evolution visual feedback, especially so if only small changes to the architecture are evaluated. Hence having a visual representation of the architecture helps differentiate deployments and focuses in on differences.

Figure 1: X-Ray view of the functional architecture vs the view of Epsagon’s automatically detected architecture

Use Invocation Count and Runtime to Identify Which Function is the Bottleneck

To identify the bottlenecks in the system, a tabular view over the runtimes of all functions is essential. This also allows us to weed out obsolete or unused functions. A similar analysis can be done for memory use.

We therefore sort by invocation count, which allows us to focus in on the most frequently used methods to target optimization efforts. We can now compare the old and new deployment side by side, by labeling one as “legacy.”

Figure 2: A tabular view of all Lambda functions and their invocation count and runtime

As seen in the functions table, the longest running function and its precursor is from the legacy deployment with its median (p50) duration :
- legacy-sgRnaFunction: 75.7 seconds
- legacy-wuCrisperFunction: 468 ms
- Total: 76 seconds
In contrast, the new tuscanRegressorFunction, which replaces the two legacy-functions, runs in just 1.6 seconds! This is a 97.8 percent reduced running time, which is 47x faster!

Assess Entire Data Flows to Target Top-Down Improvement Efforts

Complex production applications typically contain many managed services and asynchronous events, whose interplay determines the overall performance. In addition to spotting individually slow functions, it is worthwhile to evaluate entire workflows to prioritize optimization efforts to the main data flows.

For each of the GT-scan deployments, the solution identifies two flows: one comprising services watching DynamoDB and the other the API-gateway.

Comparing the two deployments at this level reveals that the main flow in GT-Scan2_legacy takes on average 97.7 seconds before the optimization, while the average runtime for the corresponding data flow in GT-Scan2_prod is 14.1 seconds—a reduction of 85.5 percent—and an overall runtime improvement of 7x!

Figure 3: Comparison between the automatically detected data flows between the prod and legacy deployment.

Visualizing the data flow of the two architectures highlights that our optimization efforts were indeed targeted at the root problem: The legacy deployment uses the two inefficient Lamdba functions, while the production deployment contains only a single more efficient function.

Figure 4: Architecture comparison of the transaction containing the difference between the prod and legacy deployment.

Bringing It All Together

Improving serverless architecture can be done systematically and efficiently by deploying the entire cloud infrastructure stack through code and using an evaluation system to automatically interrogate runtime. Specialized tools such as Epsagon can offer substantial improvements over AWS X-Ray for the evaluation step, by providing a tabular view to easily identify underperforming Lambda functions and offer an interpretable view of the architecture. Detecting data flows in the system helps prioritize optimization efforts to the main transactions of the architecture. Specialized tools help developers save time when documenting performance improvements; using hypothesis-driven evolution principles, we were able to improve the efficiency of GT-scan’s serverless system by 85 percent.

This article was co-authored by the following:

Aidan O’Brien is the main developer on the GT-Scan2 project. He is a Doctoral research student with joint appointment at CSIRO and one of the most impactful CRISPR research facilities in Australia.

Nitzan Shapira is co-founder and the CEO of Epsagon. He is a software engineer, highly experienced in infrastructure technologies and cyber-security.

Shannon Brown is the Senior Director of Growth of Epsagon. She is a software engineer with over 20 years of experience in software development, management, and sales.

— Denis Bauer
July 24, 2018
Why Serverless Needs DevOps
EDITOR’S NOTE: This article was updated July 2, 2018

Serverless, like Kubernetes and microservices, is a new technology. Yet, despite the amount of blog, forum and news-related posts published about serverless, it represents only a fraction of all IT deployments.

Aside from the new factor, serverless shares few similarities with Kubernetes and microservices. Organizations turn to Kubernetes and microservices platforms to add more agility and, in many cases, computing power to their IT operations. Serverless deployments, meanwhile, are seen mainly as a way to save resources by relegating server management to third parties.

Ultimately, cost savings is the main benefit. A successful migration largely hinges on DevOps, especially at the early adoption stage.

“There are ways to use serverless while delivering a very rich customer experience,” said Sanjay Challa, senior product marketing manager at Datical. “It is about putting the pieces together in a very right way to do that.”

More specifically, Challa said DevOps is relevant to serverless deployments because:
- DevOps promotes collaboration between development and operations — a core mantra is “you build it, you run it,” Challa said. “Serverless deployments essentially embody this central tenant: it’s frankly difficult to separate development from operations because any edit to a serverless function needs to be in the context of its operation in the cloud (the cost of the resources the function will incur and the net user experience),” Challa said.
- With serverless architecture, there is no longer a line between cloud operations engineers and developers. This is because “the roles are collapsed into one, thus embodying the fundamental core of DevOps, to collapse and harmonize the development and operations functions.” Challa said.
For data and database management, Challa said it’s also important for teams not to forget about the underlying database and data architecture, when moving to the cloud and to new serverless architectures. “If teams only focus on the application code and forget about the database, they are setup to fail as changes to the data/persistence layer simply will not be able to keep up and scale with application changes,” Challa said. “This potentially leads to quality issues, outages or even data loss in the event of a hastily made or erroneous database change.”

Serverless Not

The definition of serverless can vary, but among the many offerings available, it usually refers to functions-as-a-service (FaaS) and backend-as-a-service (BaaS) services. Despite its name, serverless has a lot to do with servers—but organizations delegate the management of those servers and the associated infrastructure to third-party cloud providers. In this way, organizations upload code or applications and the third party maintains and runs the servers. Amazon Web Services’ (AWS) Lambda, Google’s Cloud Functions, IBM’s OpenWhisk and Docker’s Serverless Docker are among the leading offerings.

When an organization decides to migrate some or all of its data to a serverless platform, it’s important to note the technology’s drawbacks, especially as they relate to DevOps. Common downsides include slower computing performance and less capacity to run code compared to what is available when using servers on-premises or on the cloud. In the case of AWS Lambda, for example, the maximum total of concurrent executions per account is set to 1,000 by default per region and memory capacity for applications is limited to just over 3GB.

Also, by shifting server management to a third party, organizations also are delegating those management functions, including many associated server-related security and monitoring capabilities.

Ultimately, it will be up to the DevOps group to weigh the advantages versus the disadvantages when deciding whether to migrate to serverless platforms. While serverless technologies could potentially frustrate some developers because of the performance constraints on computing, memory, etc.; the key issue is to choose the right tool to solve the right problem, Challa said.

“Each tool has its place,” Challa said. “Serverless is not a cure-all – but is just another tool for enterprises to consider.”

Job Description

Migrating to serverless also means job responsibilities will be affected, which will require DevOps to manage. “When you move to serverless, a lot of roles are disrupted. You need your network and infrastructure guys less than you did before, for example,” Challa said. “So, your team will look very different, since serverless teams in general looks very different compared to traditional IT operations.”

It is also necessary to solve any existing DevOps challenges you have first before you make the switch to serverless, Challa said. “Otherwise, you are setting yourself up to fail,” Challa said. “Without transparency and strong coordination, moving to the cloud and to a serverless architecture will only slow things down—or, worse, lead to outages and quality issues.”

However, once a serverless platform has been successfully set up and is running, DevOps’ workloads should decrease, since there will be less server maintenance work to do, said Holger Mueller, an analyst for Constellation Research.

“With FaaS, DevOps is less relevant as deployments take place within the FaaS framework,” Mueller said. “There is no need for DevOps to write scripts or manually do anything. Normally, everything should just run itself.”

However, Challa disagreed that serverless deployments completely run on their own once deployed. “Someone had to set up and configure a pipeline to enable developers to validate, build and ultimately deploy their serverless code. That someone must also play a DevOps function in enabling a path from a developer’s workstation to the cloud that supports the serverless capabilities—not to mention the work that needs to be done to connect the serverless application code running in the cloud to meaningful data,” he said.

— B. Cameron Gain
June 27, 2018
Serverless Computing: Moving from DevOps to NoOps

Developers rejoice as serverless computing ushers in a new era of ‘NoOps’ to replace the ill-fitted DevOps model.

While some organizations do better than others when it comes to implementing DevOps, almost everyone agrees it’s a concept easier penned to paper than pinned to reality. The idea of integrating development and operations is smart, but the implementation proves troublesome. A replacement option is thus largely welcomed by developers everywhere.

Enter the new concept of NoOps, which means dropping operations from any consideration during the development cycle. It’s not that operations are being ignored; that would be a foolhardy step backward. Rather, NoOps means never having to worry about where the code runs and, thus, developers are freed from giving operations another thought.

“Serverless computing allows users to run code without provisioning or managing any underlying system or application infrastructure, and they automatically scale to support increasing or decreasing loads,” explained Gartner serverless analyst, Arun Chandrasekaran, in a blog post.

Amazon sparked interest in serverless computing when it announced AWS Lambda at its re:Invent conference in 2014.

“I’d argue that the precursor to serverless computing is cloud IaaS, where the complexity of underlying resources—servers, storage and network—was hidden from the users, and with IaaS providing flexibility to provision unlimited compute, storage and network resources on-demand, Chandrasekaran said.

Serverless: To Use a Server or Not? ‘Tis Not the Question

Serverless computing is a developer’s dream not only because there is no longer a need to worry about where the code is going to run, but also because there is no need for direct access to the operating system to manage that code. The result: Developers can focus solely on coding—the very thing they do best!

That statement would be easier for some to understand if it were not for the utterly confounding term “serverless.” Obviously, anything requiring computing involves servers, so saying this process is serverless is simply nonsensical. While the term is unfortunate and bordering on meaningless, the concept is solidly real and more than a little familiar.

For all practical purposes, serverless is just another word for cloud but with a bit of a twist—pricing is based on the actual amount of resources consumed by an application, rather than on pre-purchased units of capacity.

Deploying Code with NoOps in a Serverless Environment

Additionally, the term “serverless code” can be used either in conjunction with code deployed in traditional styles such as microservices, e.g. loosely coupled/SOA. Or, code can be deployed in the form of full applications that can be written to require no provisioned servers.

In serverless environments, jobs are scheduled on-demand, meaning as data comes in and is available. It can be automated so that a job runs once data is received. This means that jobs run only when data exists and otherwise sit idle, where they can’t burn resources.

Economies of scale also completely change in serverless computing. That’s because serverless delivers the ability to put some intelligence behind when and where jobs run, so that they can be spun up and spun down as quickly and economically as possible.

Bottom Line

Opting for NoOps, meaning working in a serverless environment, is really a choice to be more intelligent about how resources—hardware, software and people—are being utilized. It is about cutting resource waste and associated costs, while enabling talent to focus on writing innovative code.

No job will sit there burning resources and waiting for the data to come in. Rather, the job runs on demand, as you need it, in milliseconds and without distracting you from other tasks.

“NoOps still requires connectivity so beef up your connectivity to your cloud providers, if you haven’t already. And you’ll eventually have to troubleshoot slow serverless functions as a ‘network problem,’” said Andrew Lerner, an analyst at Gartner in his post.

To gain even more advantages in serverless computing, and perhaps to make up for time lost in network troubleshooting, no matter how small, look for and use reusable code everywhere you can. Drag-and-drop interfaces that enable fast use of reusable code frees developers further, so they can shorten both the development and testing cycles. Time economy is important in modern day continuous release cycles. A NoOps and reusable code strategy can dramatically improve your time and resource economies of scale.

— Laurent Bride

June 25, 2018
Serverless: What You Need to Know

There are clear benefits to serverless architecture, with many enterprises already making or planning to make this change. Like any paradigm shift however, the move to serverless carries both benefits and risks. Here’s what you need to know.

AWS pioneered the serverless space with its release of AWS Lambda back in 2014, with the other major cloud providers following: Azure Functions as a service, Google Functions and IBM Cloud Functions (Apache Openwhisk). Later entrants in this space took the form of container-based, fully-managed serverless frameworks such as Kubeless.

The Good, the Bad and the Use Cases

Some of the most common serverless use cases today include building batch processing like image compression, cloud job automation, serving IoT devices from edge to the cloud and building single page applications (SPA).

On one hand, cloud-hosted serverless functions eliminate the overhead associated with managing actual infrastructure and introduce significant operational cost savings through efficient utilization of the underlying infrastructure. This allows developers to develop in their own comfort zone, using their language of choice: Python, JavaScript and, depending on the platform, even Go, Java, C#, PHP or others.

On the other hand, delegating the infrastructure control to the provider means that serverless introduces new set of operational blind spots and observability challenges. It also complicates the placement and management of deep security controls, when compared to container, virtual machine (VM) or even bare-metal workloads.

Serverless is Not the Answer for Everything

Whether building new applications or migrating existing ones, serverless runtimes have significant restrictions. Cloud-hosted functions-as-a-service restrict the runtime duration of a function, require a “warm-up” time for function invocation and don’t guarantee local state preservation across function invocations. This means that application logic that is purely time-bounded, involves short functional transformation of input into output and can handle a slow starting time would fit the serverless paradigm perfectly.

Migrating state-oriented applications or stateful microservices into serverless functions is a different story. This will typically make use of a database—either managed or as a service—or make use of an application cache such as Redis or object store such as S3 to store state across requests.

While cloud-hosted serverless removes the burden of patching and maintaining infrastructure, the ephemeral nature of functions makes it extremely challenging when it comes to establishing perimeters and controls around sensitive data in flight and at rest.

Build, Ship and Run Serverless

Serverless, as young as it may be, is extremely promising. Adoption choices should be balanced around platform maturity for developers, testing, operations and what security and regulations require.

If we take as an example what Docker did for container packaging, with its Container Image format, this is exactly what functions and serverless need: a common language for packaging. A common tool for building, shipping, running, operating and securing function-based workloads would serve as common ground for the variety of platforms already out there.

From a security perspective, unification around secret consumption, service-to-service authentication and authorization between first and third parties, function workflows and access whitelisting, observability, security network monitoring, access policies to the network and access policies to data—all these would lower the friction of adoption.

The Cloud Native Computing Foundation recently released version 0.1 of Cloud Events, the communication message format for function and event triggering. This emphasizes how far serverless is yet from maturity and cohesive standards.

From a security perspective, Type A serverless workload protection systems must be able to inspect the serverless workload runtime. Type B workload protection systems are limited to what the serverless platform provider APIs make available for out-of-band data-oriented security analysis.

Cloud-hosted functions makes Type A protection challenging to achieve, whereas fully managed serverless frameworks (for example, Kubeless), enables enterprises to adopt serverless and open the door for new developer experience. These also accelerate innovation velocity and, with security tools designed for microservices and modern virtualization technologies, can maintain full visibility and runtime control over network and data.

Securing Functions as a Service: A New Arsenal of Security Tools

Functions, just like any other web-based microservice implemented using containers, VMs or bare-metal server, are not free from the well-known top 10 OWASP web application vulnerability list.

Functions, however, strongly rely on non-web, event-based communications and event-based networking channels. These, on public cloud providers, prevent inserting security controls to detect exploitation attempts or data exfiltration and enforce well-defined workload policies. This requires new arsenal of security tools that understand microservices, scale horizontally and coexist with the existing security operations and security stack.

The ephemeral nature of functions-based workloads makes them more difficult to exploit, and it is definitely harder to persist a threat. Yet third-party code vulnerability or open source components gone bad can result in sensitive data flowing into the wrong hands, landing in a misconfigured object store.

As serverless requires persistent data storage in external services, a scenario in which circumventing a running function to leak secrets makes that sensitive data one hop away from an attacker is not unrealistic.

Controlling it all together: What private information can be processed, what sensitive data is in flight and through which event grid channels it’s being received and sent, along with how functions are invoked by API gateways and which API calls which functions make to internal and external services. This is where risk, regulation and modernization collide.

Bottom Line

Despite significant adoption and constantly growing interest, serverless is still in its infancy. When it comes to standards, operations, testing and orchestration tooling, workflows and security, a flood of water must yet pass under the innovation bridge of cloud providers, with AWS Lambda leading the adoption curve, Azure FaaS making giant innovative leaps forward and community-driven frameworks built on top of Kubernetes.

Innovation aside, serverless creates huge operational and security blind spots. Understanding those risks and having proper introspection and inspection capabilities is what should dictate the adoption and the choice of the platform.

— Gadi Naor

June 14, 2018
More App Dev Models Increase DevOps Pressure

A bifurcation in types of developers will become more pronounced in the years ahead as more application code moves to the network edge. As that transition continues occurring, the pressure on IT operations to be able to be able to flexibly manage different classes of applications by embracing DevOps processes will correspondingly increase.

Mike Piech, vice president and general manager of middleware for Red Hat, said applications running on internet of things (IoT) devices and smartphones present developers with a finite amount of compute resources that require them to have advanced skills. Conversely, back-end applications can now take advantage of multiple layers of abstraction, including (soon) serverless computing frameworks based on event-driven architectures that make potentially unlimited compute resources available. The availability of all those compute resources, however, encourages developers of back-end services and applications to be less disciplined when writing applications.

The good news is that it’s getting easier to right-size applications using trial and error methods versus having to commit to a specific computing architecture up front, said Piech. If something doesn’t work as well as it should, modular approaches to microservices make it possible to more easily move application code to where it should best optimally reside. Rather than focusing on the rigor of the underlying architecture, developers are free to experiment with different tools and languages more now than any time in the history of IT, he said.

In fact, Piech speculated that many graphical user interfaces will continue to run locally while accessing a wide variety of back-end services via application programming interfaces (APIs). That approach essentially creates a new form of hybrid computing wherein developers no longer need to think much about the runtime environment, he noted.

However, all that freedom tends to put a lot more pressure on the IT operations team. As the types and classes of applications continues to evolve, Piech said it’s only a matter of time before more organizations move further down the DevOps path. Adoption of DevOps processes across organizations has been somewhat uneven. But as developers experiment with different computing models, the expectation is that operating teams will be flexible enough to dynamically make the appropriate adjustments, he said.

Longer term, middleware and databases will eventually be deconstructed into sets of microservices that developers can call when needed. Today, IT operations teams make available monolithic application servers and databases. Many of those databases and application servers are starting to be encapsulated in Docker containers as part of a first step toward lifting and shifting applications into the cloud before transitioning to more agile microservices-based frameworks, Piech said.

In some cases, those services will be accessed directly via a platform-as-a-service (PaaS) environment or a serverless computing framework. Piech said Red Hat expects serverless computing frameworks based on event-driven architectures will be used mainly to provide bursting capabilities as a complement to long-running stateful applications that typically consume a fixed amount of IT infrastructure resources. It’s probable stateless applications that run intermittently also will find their way on to serverless computing frameworks. Red Hat has thrown its support behind the open source OpenWhisk serverless computing framework.

There clearly will be many more types of distributed applications running across the enterprise. IT operations teams may not have much control over what types of applications run where and when. But they will be expected to be able to deploy and manage them all, regardless.

— Mike Vizard

May 15, 2018
Why an Enterprise 5-Year Cloud Plan Must Focus on Serverless
While most of us have looked at the beginning of the new year as the time to set our personal resolutions for the next 12 months, enterprises have already started to execute their plans for the year ahead. But, that’s part of a problem. Too often major organizations move from year to year on a schedule of 12-month technology plans, never really planning or setting a path for ambitious change that will be realized in years two through five. Thinking in terms of 12-month plans, rather than a desired end state in three or five years, creates a missing-the-forest-for-the-trees effect, where enterprises can end up chasing the technology trend du jour and miss taking advantage of major disruptions to their industry.

We saw this with the cloud: Many enterprises, still focused on improving virtualization, were surprised by how quickly their developers took to the cloud to develop new applications. These same organizations have factored the cloud into their long-term planning now, but only after many others have reaped the advantages and proven it to be a great way to deliver rapid innovation. And, so far, enterprises look to be on the verge of making a similar mistake with serverless computing.

Serverless: The Ultimate Abstraction Layer

Many developers are increasingly looking to serverless computing as a faster way of developing and deploying business IT workloads. It’s not difficult to see why: Developers focus on their application and run it with third-party management; their code is only executed when prompted by predetermined triggers; it scales automatically as needed; and the business is only charged for the time that that code is actually running (as opposed to a flat rate, regardless of whether the code is running). This seems like the kind of intuitive no-brainer that enterprises should be setting a path to now.

Serverless computing is the natural outcome of the past decade of IT development, where we’ve seen different kinds of layers of abstraction being applied to hardware to create innovative new forms of growth, and do so at scale. Those layers run the gamut of:
- Virtualization, used to consolidate multiple virtual machines across a single hardware platform;
- The cloud, used to virtualize compute, networking and storage; and
- Containers, used to isolate application technology components that can be deployed and operated at scale across multiple substrates.
Following that evolution, we now have serverless computing, which takes code and functions, and executes in an environment that takes care of all the underlying infrastructure, everything from application services through operating systems, hypervisors and hardware. In other words, the ultimate abstraction layer.

Embracing Serverless Means Rethinking IT

Previous abstraction layers, such as the cloud and containerization, broke out as disruptive technologies and caught a lot of enterprises flat-footed—they hadn’t been planned for well enough in advance. Organizations needed to adjust to incorporate them into their IT workloads and business models after the fact to try and give their developers what they wanted and avoid falling behind. Consider the disadvantage that places them at when compared to cloud-first—and, increasingly, cloud-only—organizations.

Serverless promises to be even more disruptive, in no small part because it isn’t just a new layer to add on top of your hardware, as containers and the cloud were. Incorporating serverless computing into your IT environment requires a complete rethink of how your IT workloads are structured, because the serverless approach works by forcing organizations to focus on business technology as application code and not be distracted by the commodity services needed around it.

All the more reason why enterprises need to get serious now about making a long-term plan for IT that revolves around serverless computing and outsourcing IT infrastructure. Preparing for a world where the default for new applications is to be developed to run against serverless platforms will take several years. And, in fact, delaying too long will only open you to some of the challenges presented by serverless adoption: application portability, service predictability and overall failure liability.

Enterprises are understandably wary about outsourcing too much of their IT infrastructure, but the fact is, this is the direction the world is moving in. And besides, serverless isn’t solely a service offered by external cloud providers. There are many serverless platforms, such as Galactic Fog, that can be run atop of fully managed Kubernetes or OpenStack on-premises infrastructure and deliver the same benefits. Companies will only continue to outsource more and more of their IT infrastructure one way or another through 2018, putting us on track for entirely serverless businesses in just five years’ time.

While everyone is thinking about the year ahead, enterprises need to think about the next five years, whether their IT infrastructure as-is is making a difference to their business and how they can—and need to—restructure accordingly to best leverage serverless computing to their benefit.

— Mark Baker
February 28, 2018