devopsy.kinsta.cloud

Tag: serverless

  • DevOps Predictions for 2018

    DevOps Predictions for 2018

    The new year is upon us, and that can only mean one thing: outrageous tech predictions! This year, we have a few that are easy to believe and a few that are completely off-the-wall. See if you can pick them out.

    Serverless Overtakes Containers

    Serverless is the future and containers are dead. Some (or maybe even a majority) of the industry will come to realize this. Serverless is largely defined as using functions as a service (FaaS) as the backbone of your architecture. These services are a layer on top of containers that provide an opinionated way to run code that scales with demand and ties true compute usage to costs at sub-second billing increments. Much like virtualization in the data center was dwarfed by cloud providers doing opinionated virtualization a decade ago, serverless offerings will overtake the container market.

    DevOps Backlash Gets Loud

    DevOps has been happily spreading through the industry as an extension of Agile to the rest of IT. But in 2018, the pushback comes. In the early days of DevOps, there was a movement called “No-Ops.” It was championed by some, but then later, reversed back to DevOps. This year, we will see stories of failed digital transformations and DevOps attempts at conferences across the globe. At first, they will be marked as “not doing DevOps right,” but as more and more happen, they will be branded with the old-new stigma of No-Ops—and they won’t come back.

    Chaos Engineering Overtakes the Airwaves

    You remember the Chaos Monkey Netflix released to the IT world that captured the hearts and minds of software engineers everywhere? Well, this is the year when chaos reigns! We’ve already had a taste of it through the new open-source project ChaoSlingr on the Modern Security Series show at Signal Sciences, but my guess is that we are far from done. With the release of Nassim Taleb’s book “Antifragile” in 2014, this has been brewing for a few years. Expect to see more chaos-themed engineering books, conference talks and podcasts in the coming year.

    Software Flaws Mean Prison Time

    Unit testing used to seem like such a good idea, but this year it’s going to become illegal to release software without testing rigor applied. Congress has been on the edge of threatening software accountability legislation for years now, but at this point it looks unavoidable. Will this be the year that a landmark legal battle happens and an engineer who didn’t do proper testing gets thrown in jail? Don’t laugh. We have already seen the first signs of this with the VW diesel scandal; just imagine if it was a pacemaker failure. In 2018, lawyers make the new rules for software engineering.

    Promise Theory Finds New Adoption

    Mark Burgess brought physics to IT through his groundbreaking book on Promise Theory and its implications for the way our applications and infrastructure will be built over the coming years. Instead of making assertions of obligation from machine to machine, networks will be composed of voluntary agents making promises. At the time it was released, Promise Theory received a lukewarm reception. But with the new services-based architectures such as serverless and even the rise of container orchestration platforms, the industry is now ready to adopt Promise Theory thinking. Networks, applications and systems are already functioning as voluntary agents working together through promises. This year, we will see more and more mainstream adoption of the concepts and more examples of how to get it right. Get ready to learn how systems can be self-organizing.

    Application Security Becomes More About the Application

    The perennial web application security checklist is to avoid XSS, SQLi and all the rest of the OWASP Top 10. Application security will finally shift from language and framework vulnerabilities to more conversations around how applications are getting attacked. In the new year, the conversation hinges on account takeovers, fraud detection and abuse inside the application. This is good for the industry because we will move past fighting automatic scanning by adding real instrumentation to detect bad actors.

    Happy New Year!

    The next 12 months are certainly going to be an adventure, and I hope you have a happy new year.

    P.S. Please don’t get thrown in jail!

    — James Wickett

  • The Role of Operations in a No-Ops World

    The Role of Operations in a No-Ops World

    It seems that every once in a while, we in high tech get wrapped up in the next thing that will eliminate work and/or jobs. Sometimes, as is the case with DevOps, we get something that reduces redundant work and actually makes our life easier in the long run. Most of the time, however, we don’t. XML was going to end programming, Java would make everyone a programmer, SOAP meant non-programmers could piece together chunks of code and create complex systems … the list goes on and on.

    Today’s trip on the merry-go-round is for Ops and DevOps. The love in some quarters is “No-Ops”—no operations necessary at all! The data center will run itself! But where is there meat to these claims, and where is it just not possible with today’s technology? Let’s take a look.

    SaaS is Today’s No-Ops Option

    If you want a nearly complete no-ops solution today, sign up for software as a service (SaaS). You’ll still have to manage users and access—the normal AAA stuff—but the application is built and managed by someone else. That’s as close to no-ops as we have in today’s world.

    Any other solution requires a fair amount of ops, no matter what we are told. Installing servers—be they in the data center on hardware, in VMs or in cloud instances—still requires work. Even if you have a tool such as Ansible or Kubernetes cranking hard for you and doing most of the repetitive heavy lifting, you are still tying the pieces together and making things work correctly. Networking is often left to operations/DevOps teams, and making servers into cattle requires operations heavy lifting, even if you are that automated. Apps break and troubleshooting is still a largely manual exercise, with automated help in figuring out what went wrong, but the fix still heavily in the hands of operations.

    Hints at an Future Sans Operations

    As is usually the case with these claims of ending some portion of the IT workload, there is some underlying benefit if you don’t get caught up in the hype. Remember that early in cloud some were telling us that there was no longer any reason for a local data center. Of course, there are a billion reasons, and each environment is different. But there is no denying cloud has opened up how we look at server deployment. The same is true for no-ops. There are a lot of reasons that it will not actually be no-ops for an entire project (let alone an entire data center), but there are huge benefits to gain from the idea.

    Serverless

    In serverless, you develop the code behind and API, then expose the API. The system is designed to run the code only when requests come in. Application firewalling is generally mandatory and built into the system. This partially a security feature, and partially the location used to determine what code needs to be called to service a given request. The idea in the cloud is that you only pay while your API is running, and all of the operations parts of the call are taken care of for you. That’s true, if you accept that, in serverless, developers are doing operations as part of development—app firewall configuration, even the simplified version of it that serverless uses, is definitely operations, not development. And troubleshooting between serverless and server-based apps that call the API is going to fall—at least to some degree—on operations. It must, since operations are the people who have network and internetwork knowledge.

    Serverless offers some great options for deployment, though, that undeniably reduce operations overhead. For things such as cloud-bursting, the benefit is pretty undeniable. It makes pay-as-you-grow cloud into a seriously granular proposition, and can eliminate the kind of bottlenecks that all code has by spinning up a new instance for each connection.

    Container Management

    With an increasing amount of functionality folded into container management tools, the ability to auto-scale applications (or, at least, instances of a part of an application) is a big step toward no-ops. Without manual intervention, the container management tool can expand or contract the application’s footprint in response to connections, response times, etc. The built-in routing, when it fits the needs of the organization, limit the amount of networking required to facilitate this scaling also. As time goes on, expect more automation to be folded into container management to make at least the maintenance of applications easier. The advertised ability to perform rolling upgrades on applications while keeping them live is a huge operational bonus too. It’s not precisely no-ops, but it certainly is less-grey-hair-ops.

    Dev/Test/Deploy

    Application release automation, the growth of continuous test/delivery/deployment and configuration automation tools all reduce ops as well. They don’t make for no-ops, but they do facilitate the concepts, reducing operations overhead while advancing the concepts of DevOps. Expect these tools to continue to grow. Most configuration management/application deployment tools work with a selection of networking devices/appliances already, expect that trend to continue. Again, it’s a reduction in ops—not quite no-ops, but a great step in that direction.

    And More

    We’ve looked at a couple of really cool technologies that forward the reduction in operations theme beyond what is listed here. Automation of auditing and full-on automation of security testing (combining code analysis with real time data to get better coverage than today) are just two examples. Keep an eye on the market as these toolsets mature.

    Keep Kicking It

    Meanwhile, Ops isn’t going away. Stay the expert while expanding your skills. As I (and others) have said before, a tool that reduces the hands-on aspects of operations is not a threat, it’s an opportunity. That freed-up time will be useful for all those projects you wish you could do, but didn’t have the time. Or, even better (we can debate that statement later), all of those things the business wishes you could do but you don’t have time.

    In the end, you are keeping the org running, and connected to the world. Embracing the parts of no-ops that make your job easier just makes sense. Don’t fall for the hype; just pick up the good bits, and keep rocking it.

    — Don Macvittie

  • Should You Go ‘Serverless’? The Pros and Cons

    Should You Go ‘Serverless’? The Pros and Cons

    The popularity of the “serverless” term started to grow when Amazon launched AWS Lambda in 2014. Ever since, we’ve seen the term exponentially grow in use and reference, with more vendors entering the market with their own solutions (Azure recently went GA with Functions, for example).

    What is it all about and how does this new trend affect the way people write and deploy applications? Is “serverless” a paradigm shift or just a natural evolution of infrastructure as a service (IaaS) and platform as a service (PaaS)? In this post, I will discuss what “serverless” is and is not—and how it shapes up in comparison to existing PaaS solutions.

    What is ‘Serverless’?

    “Serverless” denotes a special kind of software architecture in which application logic is executed in an environment without visible processes, operating systems, servers or virtual machines. It’s worth mentioning that such an environment is actually running on the top of an operating system and uses physical servers or virtual machines, but the responsibility for provisioning and managing the infrastructure belongs entirely to the service provider. Therefore, a software developer focuses on writing code.

    In other words, a developer thinks in terms of services or functions that communicate with each other and with the external world. After implementing these services, developers using a traditional approach would combine them into a number of distributed processes when installing, running, monitoring and updating such processes for specific operating systems that are running on specific servers or virtual machines. In the “serverless” approach, a third-party service provider is responsible for everything from the processes to the operating systems to the servers.

    When a third-party service provider is responsible for the underlying IT infrastructure, a developer no longer is in charge of purchasing a dedicated server or virtual machine. At the same time, the service provider is free to decide how to efficiently utilize its infrastructure to serve requests from all of its clients. As a result, the service provider is not usually required to run a permanent workload for a specific client; instead, the software handles requests from all of the customers at the same time, spending just a limited time on handling each request from a specific customer. Therefore, such providers usually charge their customers based on the total number of requests, the frequency of requests over a specified period or the total time spent to serve all of the requests from a customer.

    The same approach works well for different types of loads because third-party service providers usually have elastic, scalable services. When customers start using a third-party service, the expected number of requests can be low and customers pay significantly less compared to purchasing, configuring and managing their own infrastructure on-premises or in the cloud. For a larger number of requests—either expected or unexpected load peaks—customers do not need to add servers to horizontally scale their application. Instead, a service provider does care about increased load. For sure, handling a bigger number of requests will cost more, but in most cases it is still more efficient than using a dedicated IT infrastructure.

    BaaS and FaaS

    Two approaches that often are mentioned together with serverless are backend as a service (BaaS) and function as a service (FaaS).

    BaaS

    The growing number of third-party services that implement required functionality, provide server-side logic and manage their internal states has led to applications that do not have application-specific, server-side logic and use third-party services for everything. In this respect,  such applications are serverless.

    Some examples of third-party services include identity and authentication as a service (Auth0, AWS Cognito), logging as a service (Loggly, Logsense, Amazon Elasticsearch Service) and analytics as a service (Amazon Kinesis, Keen IO).

    FaaS

    When an application still requires specific server-side logic, a developer can use a modern alternative to traditional architectures: FaaS. With this approach, a developer focuses on implementing short-living stateless functions that are triggered by events and can communicate with each other and the external world. A FaaS provider does the rest—provisioning as many instances of such functions as necessary to handle all of the requests, terminate instances that are no longer required, monitor all of them and provide identity and logging services. FaaS ideally fits with microservices architecture because the FaaS provides everything that an organization needs for running microservices.

    Auth0 Webtask, AWS Lambda, Google Cloud Functions and Azure Functions are examples of FaaS implementation. IronFunctions is an ambitious initiative from Iron.io that is targeted to run AWS Lambda functionality on the most popular cloud providers as well as on-premises.

    What is Not ‘Serverless’?

    The main difference between serverless and PaaS is that traditional PaaS providers such as Heroku or OpenShift usually lack the automatic scaling feature. A user of traditional PaaS has to specify the amount of resources—such as dynos for Heroku or gears for OpenShift—for the application. It still is possible to manually scale the application up or down by changing the number of assigned resources, but mostly this is the responsibility of a developer or system administrator.

    The second difference is that traditional PaaSes are designed for long-running server applications. With such a design, the application always should be running to serve incoming requests. If you bring the application down, it obviously will not serve the requests. With FaaS, your function starts to serve a request and terminates when the request is processed. Ideally, your functions should not consume provider resources when there are no incoming requests (see also “cold start” issue below).

    Traditional PaaS implementations are not “serverless” under the strict definition of this term because they do not have automated scaling and require that server-side applications are always running so that requests can be served. Traditional container management platforms are not “serverless” for the same reasons.

    Another way to know if a provider allows the serverless approach is to identify the border between two areas of responsibility: the provider’s consumer and the provider itself. In “serverless,” the border is between application code and how is this code is actually deployed and running on physical servers. In container platforms, a platform’s consumer is still responsible for working with the operating-system level to define things such as the processes that will run in which containers and how many containers of each kind will run.

    Nonetheless, there is an inherent similarity between containers and serverless. For example, Kubernetes—an open-source container orchestration platform—allows for the automated scaling of containers using application-provided metrics such as the number of concurrent requests. AWS Lambda actually runs a container for each function.

    In other words, containers and container orchestration may provide an efficient way to implement FaaS while FaaS provides an additional abstraction level that hides specific processes, operating systems and containers from developers and allows them to focus on code.

    The Benefits and Drawbacks of “Serverless”

    As we already mentioned, “serverless” has the following main benefits:

    • Reduced time to market and quicker software release.
    • Lower operational and development costs.
    • A smaller cost to scale – there is no need for developers to implement code to scale and administrators do not need to upgrade existing servers or add additional ones.
    • Works with agile development and allows developers to focus on code and to deliver faster.
    • Fits with microservices, which can be implemented as functions.
    • Reduces the complexity of software.
    • Simplifies packaging and deployment and requires no system administration.

    At the same time, “serverless” has the following drawbacks:

    • Serverless is not efficient for long-running applications. In certain cases, using long tasks can be much more expensive than, for example, running a workload on a dedicated server or virtual machine.
    • Vendor lock-in. Your application is completely dependent on a third-party provider. You do not have a full control of your application. Most likely, you cannot change your platform or provider without making significant changes to your application. Also, you are dependent on platform availability, and the platform’s API and costs can change. Needles to say, the existing FaaS implementations are not compatible with each other.
    • Serverless (and microservice) architectures introduce additional overhead for function/microservice calls. There are no “local” operations; you cannot assume that two communicating functions are located on the same server.
    • To utilize its resources more efficiently, a service provider may run software for several different customers on the same physical server (this is also known as “multitenancy”). Even if customers’ workloads are isolated in virtual machines or containers, there can be different bugs in the early stages of FaaS offerings. This can be a major security issue for your application if you work with sensitive data. Such potential bugs in a platform or failures in one customer’s code (a “noisy neighbor”) can affect the performance or availability of your application.
    • In practice, it takes some time for a scalable serverless platform to handle a first request by your function. This problem is know as “cold start”—a platform needs to initialize internal resources (AWS Lambda, for example, needs to start a container). The platform may also release such resources (such as stopping the container) if there have been no requests to your function for a long time. One option to avoid the cold start is to make sure your function remains in an active state by sending periodic requests to your function.
    • Some FaaS implementations—such as AWS Lambda—do not provide out-of-the-box tools to test functions locally (assuming that a developer will use the same cloud for testing). This is not an ideal decision, especially considering that you will pay for each function invocation. As a result, several third-party solutions are trying to fill this gap, enabling you to test functions locally.
    • Different FaaS implementations provide different methods for logging in functions. For example, AWS Lambda allows writing logs to AWS CloudWatch using the standard frameworks for the specific language (Log4j for Java, console methods for Node.js, logging module for Python). It is completely up to the developer how to implement more advanced logging.

    Summary

    Serverless architecture is a new approach to writing and deploying application that allows developers to focus on code. Such an approach can reduce time to market, operational costs and system complexity. While serverless leverages third-party services such as AWS Lambda to eliminate the requirement to set up and configure physical servers or virtual machines, it also locks in the application and its architecture to the specific service provider. In the future, we can expect more movement toward the unification of FaaS APIs or frameworks such as IronFunctions that will help to avoid vendor lock-in and enable us to run serverless applications on different cloud providers or even on-premises.

    — Asaf Yigal

  • Native Docker for Windows Arrives: Are Containers Finally Serverless?

    Native Docker for Windows Arrives: Are Containers Finally Serverless?

    Is Docker finally ready for the age of serverless computing? That’s the message from the announcement this week of native Docker container support for Windows Server 2016.

    If you’ve been following Docker for a while, you know that Docker containers originally supported only Linux operating systems. Then, Docker made its platform available for Windows users, too—but with the major caveat that Docker Engine ran inside a Linux-based virtual machine image on top. So, you could run Docker from Windows, but Linux was still the middleman.

    Real Docker Containers

    This week, that all changed. On Sept. 26, Docker announced the general availability of native Docker container support on Windows Server 2016. By “native,” Docker means that the containers run using new primitives—the equivalent of namespaces in Linux—that are built into the Windows kernel itself. There’s no more virtualization.

    But that’s not all. The complete Docker tool set also now runs natively on Windows. The Docker CLI, Swarm orchestration, data volumes and all the other building blocks of a Dockerized infrastructure are officially compatible, as well as Docker containers themselves.

    The support is the result of more than two years of collaboration between Docker and Microsoft, which is now a Top Five contributor to the Docker open-source project.

    Caveats

    Native support for Docker is a big accomplishment. But there are still some limitations, including:

    • Docker containers can only run natively on Windows Server 2016 and Windows 10. Other versions won’t work with Docker because they lack the kernel enhancements necessary to support Docker containers, Scott Johnston, Docker COO, explained in an interview.
    • Some advanced networking configuration features for Docker are not yet supported because the “plumbing” required to make those features work is not complete inside the kernel, Johnston said, adding Microsoft is working to change that.
    • Most notably, Docker containers on Windows can only run Windows apps inside the containers. In other words, you can’t run an app compiled for Linux inside a Docker container running on Windows. You would need a Windows host to do that. (And the opposite holds true: You can’t run Windows apps inside Docker containers on a Linux host.) This is not something that will change, according to Johnston.

    Docker Becomes Serverless

    Docker the company is celebrating the support as an opportunity to expand the Docker ecosystem immensely. Support for Windows “doubles the potential market opportunity” for Docker partners, the company said in a presentation about the announcement. (By the way, Docker has good reason to want to keep its partners happy by giving them a larger ecosystem to work with. The integration of Swarm into Docker earlier this year undercut the value of some of Docker’s partners’ products. But I digress.)

    The most interesting aspect of this news from a DevOps perspective, however, is that it means Docker is now much more serverless. A large part of the value of Docker containers is their ability to simplify application delivery. As long as you can package your app as a Docker container, you can deploy it on any server that has Docker running.

    You don’t have to think about the underlying server hardware or configuration. In other words, Docker allows you to become serverless, because you no longer have to think very much about the server you are deploying to.

    Previously, however, this flexibility was limited by the fact that you did have to think about the server OS. Now, with native Docker support for Windows, that’s no longer the case. It doesn’t matter whether your infrastructure is composed of Windows servers, Linux servers or both. As long as you install Docker on them, you can deploy to any server.

    Of course, there is still the issue of having to make sure your app is compiled for the right operating system. But that is easy enough to manage in most cases during the build process.

    — Chris Tozzi