Before we get down to the proverbial “can do”, a few tools and utilities have to be installed:

• Minikube [2]
• kubectl [3]
• kubens [4]

For Windows users, WSL [5] has proven to be quite useful, so I recommend installing that as well.

Setting up Minikube

Minikube is a single node Kubernetes cluster that is ideal for everyday development with Kubernetes. After the setup, the following steps must be performed to make Minikube ready for deployment with Knative Serving. Listing 1 shows what this looks like in the code.

Listing1
minikube profile knative 

minikube start -p knative --memory=8192 --cpus=6 \
  --kubernetes-version=v1.12.0 \
  --disk-size=50g \
  --extra-config=apiserver.enable-admission-plugins="LimitRanger,NamespaceExists,NamespaceLifecycle,ResourceQuota,ServiceAccount,DefaultStorageClass,MutatingAdmissionWebhook" 

First, a Minikube profile must be created, which is what the first line achieves. The second command is then used to set up a Minikube instance that contains 8 GB RAM, 6 CPUs and 50 GB hard disk space. The boot command also contains a few additional configurations for the Kubernetes cluster that are necessary to get Knative up and running. It is also important that the used Kubernetes version is not older than version 1.12.0, otherwise Knative will not work. If Minikube doesn’t start immediately, it’s completely normal; it can take a few minutes until the initial startup is complete, so you should be a little patient when setting it up.

Want more great articles about Serverless Architecture? Subscribe to our newsletter!

Leave this field empty if you're human:

Setting up an Istio Ingress Gateway

Knative requires an Ingress Gateway to route requests to Knative Services. In addition to Istio [6], Gloo [7] is also supported as an Ingress Gateway. For our example we will use Istio, though. The following steps show how to perform a lightweight installation of Istio that contains only the Ingress Gateway:

curl -L https://raw.githubusercontent.com/knative/serving/release-0.6/third_party/istio-1.1.3/istio-lean.yaml \
| sed 's/LoadBalancer/NodePort/' \
| kubectl apply --filename –

Like the setup of Minikube, the deployment of the Istio Pod takes a few minutes. With the command kubectl —namespace istio-system get pods –watch you can see the status; the overview is finished with Ctrl + C. Whether the deployment was successful or not can be easily determined with the command kubectl –namespace istio-system get pods. If everything went well, the output should look like Listing 2.

Listing 2
NAME                                     READY   STATUS    RESTARTS   AGE
cluster-local-gateway-7989595989-9ng8l   1/1     Running   0          2m14s
istio-ingressgateway-6877d77579-fw97q    2/2     Running   0          2m14s
istio-pilot-5499866859-vtkb8             1/1     Running   0          2m14s

Installing Knative Serving

The installation of Knative Serving [8] allows us to run serverless workloads on Kubernetes. It also provides automatic scaling and tracking of revisions. You can install Knative Serving with the following commands:

kubectl apply --selector knative.dev/crd-install=true \
--filename https://github.com/knative/serving/releases/download/v0.6.0/serving.yaml

kubectl apply --filename https://github.com/knative/serving/releases/download/v0.6.0/serving.yaml --selector networking.knative.dev/certificate-provider!=cert-manager

Again, it will probably take a few minutes until the Knative Pods are deployed; with the command kubectl –namespace knative-serving get pods –watch you can check the status. As before, the check can be aborted with Ctrl + C. With the command kubectl –namespace knative-serving get pods you can check if everything is running. If this is the case, an output like in Listing 3 should be displayed.

Listing 3
NAME                               READY   STATUS    RESTARTS   AGE
activator-54f7c49d5f-trr82         1/1     Running   0          27m
autoscaler-5bcd65c848-2cpv8        1/1     Running   0          27m
controller-c795f6fb-r7bmz          1/1     Running   0          27m
networking-istio-888848b88-bkxqr   1/1     Running   0          27m
webhook-796c5dd94f-phkxw           1/1     Running   0          27m

Deploy demo application

The application we want to create for demonstration is a simple greeting machine that outputs “Hi”. For this we use an existing Linux container image, which can be found on the Quay website [9].
The first step is to create a traditional Kubernetes deployment that can then be modified to use serverless functionality. This will make clear where the actual differences lie and how to make existing deployments using Knative serverless.

Create a Kubernetes resource file

The following steps show how to create a Kubernetes resource file. To do this, you must first create a new file called app.yaml, into which the code in Listing 4 must be copied.

Listing 4
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: greeter
spec:
  selector:
    matchLabels:
      app: greeter
  template:
    metadata:
      labels:
        app: greeter
    spec:
      containers:
      - name: greeter
        image: quay.io/rhdevelopers/knative-tutorial-greeter:quarkus
        resources:
          limits:
            memory: "32Mi"
            cpu: "100m"
        ports:
        - containerPort: 8080
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: greeter-svc
spec:
  selector:
    app: greeter
  type: NodePort
  ports:
  - port: 8080
    targetPort: 8080

Create the deployment and service

By applying the previously created YAML file, we can create the deployment and service. This is done using the kubectl apply –filename app.yaml command. Also, at this point, the command kubectl get pods –watch can be used to get information about the status of the application, while CTRL + C terminates the whole thing. If all went well, we should now have a deployment called greeter and a service called greeter-svc (Listing 5).

 
Listing 5
$ kubectl get deployments
NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
greeter   1         1         1            1           16s

$ kubectl get svc
NAME          TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
greeter-svc   NodePort    10.110.164.179           8080:31633/TCP   50s

To activate a service, you can also use a Minikube shortcut like minikube service greeter-svc, which opens the service URL in your browser. If you prefer to use curl to open the same URL, you have to use the command curl $(minikube service greeter-svc –url). Now you should see a text that looks something like this: Hi greeter => ‘9861675f8845’ : 1

Migrating the traditional Kubernetes deployment to serverless with Knative

The migration starts by simply copying the app.yaml file, naming it serverless-app-yaml and updating it to the lines shown in Listing 6.

Listing 6
---
apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: greeter
spec:
  template:
    metadata:
      labels:
        app: greeter
    spec:
      containers:
      - image: quay.io/rhdevelopers/knative-tutorial-greeter:quarkus
        resources:
          limits:
            memory: "32Mi"
            cpu: "100m"
        ports:
        - containerPort: 8080
        livenessProbe:
          httpGet:
            path: /healthz
        readinessProbe:
          httpGet:
            path: /healthz

If we compare the traditional Kubernetes application (app.yaml) with the serverless application (serverless-app.yaml), we find three things. Firstly, no additional service is needed, as Knative will automatically create and route the service. Secondly, since the definition of the service is done manually, there is no need for selectors anymore, so the following lines of code are omitted:

 selector:
        matchLabels:
          app: greeter

Lastly, under TEMPLATE | SPEC | CONTAINERS name: is omitted because the name is automatically generated by Knative. In addition, no ports need to be defined for the probe’s liveness and readiness.

Deploying the serverless app

The deployment follows the same pattern as before, using the command kubectl apply –filename serverless-app.yaml. The following objects should have been created after the successful deployment of the serverless application: The deployment should now have been added (Listing 7). A few new services should also be available (Listing 8), including the ExternalName service, which points to istio-ingressgateway.istio-system.svc.cluster.local. There should also be a Knative service available with a URL to which requests can be sent (Listing 9).

Listing 7
$ kubectl get deployments
NAME                       DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
greeter                    1         1         1            1           30m
greeter-bn8cm-deployment   1         1         1            1           59s

Listing 8
$ kubectl get services
NAME                    TYPE           CLUSTER-IP       EXTERNAL-IP                                           PORT(S)          AGE
greeter                 ExternalName              istio-ingressgateway.istio-system.svc.cluster.local              114s
greeter-bn8cm           ClusterIP      10.110.208.72                                                    80/TCP           2m21s
greeter-bn8cm-metrics   ClusterIP      10.100.237.125                                                   9090/TCP         2m21s
greeter-bn8cm-priv      ClusterIP      10.107.104.53                                                    80/TCP           2m21s

Listing 9
kubectl get services.serving.knative.dev
NAME    URL                                LATESTCREATED   LATESTREADY     READY   REASON
greeter http://greeter.default.example.com greeter-bn8cm   greeter-bn8cm   True

Attention
In a Minikube deployment we will have neither LoadBalancer nor DNS to resolve anything to *.example.com or a service URL like http://greeter.default.example.com. To call a service, the host header must be used with http/curl.

To be able to call a service, the request must go through the ingress or gateway (in our case Istio). To find out the address of the Istio gateway we have to use in the http/curl call, the following command can be used:

IP_ADDRESS="$(minikube ip):$(kubectl get svc istio-ingressgateway --namespace istio-system --output 'jsonpath={.spec.ports[?(@.port==80)].nodePort}')"

The command receives the NodePort of the service istio-ingressgateway in the namespace istio-system. If we have the NodePort of the istio-ingressgateway, we can call the greeter service via $IP_ADDRESS by passing the host header with http/curl calls.

curl -H "Host:greeter.default.example.com" $IP_ADDRESS

Now you should get the same answer as with traditional Kubernetes deployment (Hi greeter => ‘9861675f8845’ : 1). If you allow the deployment to be in idle mode for about 90 seconds, the deployment will be terminated. At the next call, the scheduled deployment is then reactivated, and the request is answered.

Congratulations, you have successfully deployed and called your first serverless application!

Links & Literature

The post Your first step towards serverless application development appeared first on Serverless Architecture Conference.

In the traditional testing pyramid we’re all familiar with, unit tests sit at the bottom, component testing in the middle, and user interface testing at the top. The reason for this is simple: most emphasis is placed on the cheapest, least complex, and most easily automatable tests.

Unit tests are simplest to write and perform, so by focusing on unit tests we’re able to get the best possible testing coverage for our software.
Component – or Integration – testing sits in the middle and focuses on the interaction between the various component parts of our application.
User interface testing is the most difficult of the three types of tests to automate (though there are many tools for the task, these types of tests are the first to break after any small change in the software), and typically has been performed by a separate QA or testing department.
So, how do things change in the world of serverless? You’ll be glad to know we still have a pyramid with the same familiar parts. The difference now is that we need to place much more emphasis on component testing than before. Our pyramid has become slightly misshapen.

This is a shift we already saw in the move to microservices, but it’s become even more critical in serverless applications (that many refer to as nano services), which are typically comprised of a complex web of ephemeral functions and third-party services such as DynamoDB, Kinesis, S3 and so on.
Not only is serverless even more granular than microservices, but since your application exists entirely on the cloud, and you do not own all the code that makes it up, it becomes difficult to test locally.

The limits of local testing in serverless

Unit testing for serverless applications can be (and is) conducted locally with the same ease as for other architectures. So, let’s skip over our pyramid’s foundation and focus on the more interesting question: is it good practice to perform component testing on your local machine?

After all, it’s easier to test locally, where you have visibility over your entire environment, not to mention cheaper, since you don’t have to pay your cloud service provider for a testing environment.
Tools, such as Lambda-local and LocalStack, do allow you to do this, not to mention two of the most popular deployment tools, AWS SAM and Serverless Framework. There are also mocks for some of the most commonly used managed services. But while it’s technically possible to test your application locally, there are some major disadvantages to doing so. The first and most obvious issue is that while official and unofficial mocks exist for many of the managed services we use in production, there are notable absences such as Kinesis and SQS, as well as non-AWS services like Auth0.

And even for those that do exist, mocks may not have all the features that the most updated live version of the services have (the open source mocks are not updated at the pace of the AWS managed services). But one of the biggest reasons to test in the cloud is the importance of configuration to the smooth running of a serverless application. Many of the issues we run into come down to improper configuration of the managed services held together by our Lambdas. When testing against local mocks everything may appear fine, but in production the interaction between various other components may cause issues we didn’t foresee

Serverless component testing should be done in the cloud

Testing in the cloud is the only way to ensure that everything is configured correctly. It’s also the only way to test against the various limitations set by the cloud service providers.
There are limitations set by AWS on the number of concurrent functions (this is currently set to a maximum of 1,000 concurrent executions per account) and on how long a Lambda function can run (at the moment the timeout limit is 900 seconds).

Testing in the cloud is the only way to ensure that everything is configured correctly. It’s also the only way to test against the various limitations set by the cloud service providers.
There are limitations set by AWS on the number of concurrent functions (this is currently set to a maximum of 1,000 concurrent executions per account) and on how long a Lambda function can run (at the moment the timeout limit is 900 seconds).

Efficiency and cost can also only be tested properly in the cloud. We pay based on the amount of memory we allocate to a function and the duration of execution. Assigning more memory can lead to much faster execution (as the number of cores AWS assign to the task is based on the amount of memory requested), and the trick is to find the right balance to ascertain the most cost-effective allocation. We can only deduce this by testing in the cloud environment.

While testing in the cloud is more expensive, because every developer will need their own account specifically for testing, it isn’t prohibitively so, even for larger teams.
The main problem is with the extra time that it takes to deploy everything to the cloud for testing. At Lumigo we use a simple bash script to automatically check whether any changes have been made to the application. If so, we deploy the whole lot to the cloud for testing. If not, we only need to deploy the function that we wish to test.

The post Adapting Testing for Serverless Applications appeared first on Serverless Architecture Conference.

The post Going FaaSter: Cost-Performance Optimizations of Serverless on Kubernetes | Erwin van Eyk appeared first on Serverless Architecture Conference.

The post All you need to know about terraform appeared first on Serverless Architecture Conference.

The post Serverless Testing: the required Adaption to our Testing Methodologies | Avishai Shafir appeared first on Serverless Architecture Conference.

Let your boss know why you want to go to Serverless Architecture Conference

Tell him the Serverless Architecture Conference will be held together with API Conference. In total there are over 45 sessions, workshops and keynotes addressing actual trends and best practices which will be presented by more than 40 international speakers and industry experts.

Tell your boss to take a look at the conference tracks to have a better idea of what this conference is all about.

Tell him what’s in it for him

You have the chance to gain key knowledge and skills for this new era of computing. Turn your ideas into best practices during the workshops and meet people who can help you with that. You’ll learn what it means to build up a serverless-first mindset with numerous real-world examples and you can put them into practice in your company.

Show him that you’ve done your homework: Book your ticket by September 12 and save € 100

If you book your ticket by September 12, your boss will pay € 100 less on the early bird ticket. Plus, you will have an additional 10% discount for a group of 3 people or more.

Assure your boss that you will network with top industry experts

In addition to the valuable knowledge you will get from top-notch industry experts, you’ll also have the chance to connect and network with the people who are at the top of their career. Serverless Architecture Conference offers an expo reception and a networking event.

The post Top 5 reasons to attend Serverless Architecture Conference appeared first on Serverless Architecture Conference.

Serverless Architecture editorial team: Serverless as a term is a rather controversial buzzword: Servers are still in use. In addition, everyone seems to understand  serverless as something different (i.e. FaaS or BaaS). What is serverless for you personally?

Lee Atchison: For me, the most useful definition of serverless is any platform-level service that provides capabilities to its customers without the customers needing to know or understand the underlying infrastructure that is running the service.

Using this definition as a baseline, FaaS offerings such as AWS Lambda would certainly qualify, but, on the same note, Amazon S3 would be considered as a serverless offering as well.

Amazon S3 provides storage capability as a service without the consumer needing any knowledge or understanding of the underlying infrastructure that operates the service.

The best way to look at the distinction between server based and serverless services is to look at the difference between Amazon DynamoDB and Amazon RDS.

Both of them are database offerings. DynamoDB is serverless because you do not have to know or understand the underlying server architecture. Amazon RDS is server-based, because you have to know and understand the servers where the service operates, and with that understanding comes a requirement for you to configure to size the servers properly and build in appropriate redundancy and backups. These two services are a great way to compare server-based and serverless services.

Examples of AWS Serverless services:

• AWS Lambda
• DynamoDB
• SNS/SQS
• CloudFront

Examples of AWS Server-based services:

• RDS
• ElastiCache
• ECS/EKS
• Elastic Beanstalk

Overall, it is easier to configure and scale serverless services than it is server-based services.

Serverless Architecture editorial team: From a developer’s point of view, serverless has many advantages. One is that you practically don’t have to worry about the infrastructure anymore. In your opinion, how does serverless change the everyday life of developers?

Lee Atchison: Developers, especially those that are building, deploying, and operating services using DevOps methodologies, benefit greatly from cloud-based infrastructure services. Serverless technologies, in particular, enable using and scaling infrastructure services more efficient for your everyday developer. Furthermore, developers can now take advantage of managed services that allow them to build everything from simple event-based workloads to complex video pipelines, all without managing the intricacies of running any servers. The low overhead to start using these services and the minimal level of effort required to build and maintain production workloads on them give software engineers the opportunity to speed innovation.

However, that does not mean that all problems are solved for the developer. As a simple example, users of AWS Lambda still have to consider performance and scaling because the performance characteristics of a particular AWS Lambda function could vary depending on the use patterns of the function and at what scale it operates. These variances can have an adverse impact on the ease and convenience of operating serverless based infrastructures. Put simply, just because you don’t have to scale your servers does not mean you don’t have to think about and deal with scaling issues.

Put simply, just because you don’t have to scale your servers does not mean you don’t have to think about and deal with scaling issues.

Serverless Architecture editorial team: Developers aren’t the only ones affected by the new model, especially when you think of DevOps: What are the consequences of the serverless approach for Operators/System Administrators?

Lee Atchison: The same challenges that affect the developer also affect the modern operations personnel. As we move forward, these roles are becoming very much intertwined in the world of DevOps.

However, the need for infrastructure operations management will continue to be essential. Operations teams will still be responsible for making sure the environments being created are properly configured for failover. Additionally, Ops will be responsible for monitoring cloud services which will give them essential information to improve future cloud service usage. Operations teams are uniquely suited to support organizations during this next phase of the serverless journey.

Serverless Architecture editorial team: In the context of DevOps, observability and monitoring are very important topics. How does observability work in serverless applications, since you are not in charge of the underlying infrastructure anymore as an Operator?

Lee Atchison: Observability is much more involved in the end-to-end, full-stack application view as well as the low-level details of the infrastructure that it is running on. Observability capabilities, such as tracing, are becoming significantly more important. Additionally, capabilities to combine high-level observability patterns (such as application tracing) along with lower level monitoring capabilities (such as server monitoring, Kubernetes/container monitoring, and cloud service monitoring) in a single, unified view that allows you to compare and identify causal relationships is becoming more and more critical.

For example, a service may be failing its SLA’s due to a back-end dependency. What observability enables teams to do is, quickly see and understand that dependency is using a cloud service that is currently experiencing issues. It is critical that teams have this ability in order to keep their services up and running.

SEE ALSO: Grails 4 – Groovy goes serverless with Micronaut

Serverless Architecture editorial team: Simon Wardley has put forward the thesis that containers and Kubernetes are only a marginal phenomenon in the history of software development and could soon become obsolete, since “serverless is eating the world.” What do you think of that?

Lee Atchison: Serverless technologies enable engineers to build modern applications with increased agility and lower total cost of ownership. Building serverless applications means that your developers can focus more of their time on delivering the core product, rather than managing and operating servers or runtimes. This reduced overhead lets developers reclaim time and energy that can be spent on developing great products which scale and that are reliable.

Container technology will also be a major piece of the puzzle that will be a critical component in building and maintaining modern applications in the future.

Serverless Architecture editorial team: Finally, a brief look into the crystal ball: What role will serverless play in 2020?

Lee Atchison: Serverless will be one of the critical services that, together with other modern technologies, can be described as “Dynamic Infrastructures.” Overall, dynamic infrastructures will be used to build highly scalable, highly available, service-based applications that will form the heart of our modern world.

In the next year, expect serverless to become more mainstream in enterprise applications and more integrated with other technologies such as microservices and traditional application architectures. Serverless won’t necessarily replace the need for traditional computation, and we will see significant growth in Kubernetes and container-as-a-service models in the future.

Thank you!

The post “Expect serverless to become more mainstream” appeared first on Serverless Architecture Conference.

The post GraphQL, Serverless and the Cloud-native State of the Art appeared first on Serverless Architecture Conference.

Erwin van Eyk: Serverless indeed remains a controversial term to use. On the one hand, many people argue for various restrictive definitions to comprise a specific cloud model (such as FaaS) or very specific constraints (such as “it is only serverless when it is managed by a cloud provider”). On the other hand, others try to stretch the definition of “serverless” to ensure that the buzzword also applies to a certain service, product or application.

Personally, I don’t think an exact definition is either desirable or achievable. The emergence and subsequent controversy behind serverless feel oddly reminiscent of the early days of the previous buzzword: “cloud computing”. Back when AWS and other key players popularized that buzzword, there was a lot of controversy around its use. What exactly is cloud computing? When is a service a cloud service, and when is it not? If you look back, various strict definitions were proposed, but we never settled on a clearly delineated definition. Take, for instance, the current cloud computing definition by Merriam-Webster: “The practice of storing regularly used computer data on multiple servers that can be accessed through the Internet” – if that is not a broad, vague definition, I don’t know what is.

This is not to say that we don’t need a bit more structure in the definition of what serverless constitutes. To introduce a bit more structured definition, I, together with an international team of researchers and industry professionals, proposed a definition of serverless computing based on three key characteristics:

1. Granular billing: The service only bills the user for actual resources used to execute business logic. For example, a traditional VM does not have this characteristic because users are billed hourly for resources regardless of whether they are used.
2. Minimal operational logic: Operational logic, such as resource management, provisioning, and autoscaling, should be delegated as much as possible to the cloud provider.
3. Event-driven: User applications (whether they are functions, queries, or containers) should only be active/deployed when they are needed; when an event triggers the need for it.

With this definition, FaaS, BaaS, and even some SaaS services are part of the serverless computing domain. If an application, product or service adheres to these three characteristics, call it serverless by all means.

Serverless Architecture Conference: From a developer’s point of view, serverless has many advantages, one of which is that you practically don’t have to worry about the infrastructure anymore. In your opinion, how does serverless change the everyday life of developers?

Erwin van Eyk: There seems to be a lot of talk about how serverless will radically change the lives of developers. However, serverless computing is simply the next step in the perpetual trend in cloud computing. We are continuously trying to move to higher levels of abstractions with our applications, bringing programming closer to the business domain and away from the operational details.

With serverless, we simply continue this trend of higher levels of abstraction.

Cloud computing provided us with an abstraction layer over bare-metal machines.

Serverless computing takes the next step, abstracting away virtual machine logic for developers.

Serverless Architecture Conference: Developers aren’t the only ones affected by the new model, especially when you think of DevOps: What are the consequences of the serverless approach for operators/system administrators?

Erwin van Eyk: Serverless is unlikely to completely remove the need for system administrators or operators. Instead, it will promote more specialization in DevOps. The separation between business logic and operational logic in serverless means that DevOps engineers can specialize in the maintenance and improvement of the common operational layers. On the user side, engineers are needed to monitor, albeit at a higher level, the serverless functions and other services.

Serverless Architecture Conference: Simon Wardley has put forward the thesis that containers and Kubernetes are only a marginal phenomenon in the history of software development and could soon become obsolete, since “serverless is eating the world.“ What do you think of that?

Erwin van Eyk: While serverless computing is the fastest growing part within the cloud ecosystem and its promise is clear, it is too extreme to state that it will make all other cloud models obsolete. Use cases will remain that require the use of bare-metal machines rather than serverless services. However, existing cloud models and technologies are moving and will move further towards serverless. For example, many projects, such as service meshes (e.g., Istio, Linkerd, etc.) and FaaS platforms (e.g., Knative and the open source Fission, have emerged to further abstract away operational details of containers and Kubernetes. Instead of becoming obsolete, Kubernetes holds a nice promise of a unified ecosystem in which serverless/FaaS services coexist with more traditionally deployed services.

Serverless Architecture Conference: Serverless is all about scalability and the associated costs: Is it still worth using your own servers today, or is the price/performance ratio of Serverless unbeatable?

Erwin van Eyk: The price/performance ratio of serverless platforms is certainly not unbeatable. The internet is full of one-to-one comparisons between serverless and non-serverless alternatives. For example, if you compare the pricing of AWS Lambda to deploying the same service on an EC2 instance, you will find that, as you increase the number of function executions, the cost of the FaaS function quickly exceeds that of renting a VM.

Yet, even at such discounts one of the key costs remains: operating costs. Deploying a couple of VMs to run your application is only the start. After the deployment you will have to monitor your application; keep the machine, middleware and application up to date; scale the number of VMs up and down according to demand (or monitor the autoscaling policies that do so for you). This maintenance and support will consume the costly time of already scarcely available DevOps engineers.

Still, there are cases in which it is more cost-effective to deploy these applications in traditional close-to-metal cloud models. When the workload is large, relatively stable, or performance is critical, it can be cheaper and safer to have on-prem dedicated resources.

But, in most cases, the microservices that we write are not that performance-critical, nor do they have a consistent, large workload. In such cases, we can save costs by deferring the operations to a cloud provider. The cloud provider (which can simply be an internal operations team), running a self-managed FaaS platform, such as the open source Fission, can benefit from the economies of scale, multiplexing the serverless applications on fewer machines, while providing the applications with extensive autoscaling.

Serverless Architecture Conference: Finally, a brief look into the crystal ball: What role will serverless play in 2020?

Erwin van Eyk: Serverless will play an increasingly important role in how we use and think about distributed cloud applications. Although there are too many challenges and opportunities in serverless computing to describe, I believe on a user-level we will see the following trends develop further:

1. The tooling around (open-source) serverless platforms will improve to allow more complex serverless applications. Systems that allow for the composition of serverless functions and services, such as workflow systems, will mature. This will encourage the reuse of existing functions and simplify the implementation of cross-cloud operations.
2. The emergence of edge computing will further amplify the popularity of serverless computing. The on-demand, lightweight, and ephemeral nature of FaaS functions, for example, makes them ideal candidates to serve workloads at the edge.
3. New programming models will emerge that leverage serverless computing to help developers to define their distributed applications.

Overall, I believe that the concepts behind serverless computing, despite all the buzzwords, are here to stay, and will continue to trend towards higher-level abstractions for cloud computing.

The post “Serverless is unlikely to completely remove the need for system administrators or operators” appeared first on Serverless Architecture Conference.

The post Distributed Tracing: Modern Debugging in Times of Serverless appeared first on Serverless Architecture Conference.