Congratulations on completing the book. In our opinion, you should be well-equipped for your next project using Serverless Swift and Apache OpenWhisk. In this chapter, we will summarize key points, use cases, and patterns as well as provide references to further resources which may be useful in taking your next steps along the road to Serverless mastery.
Summary of topics and key takeaways
Introducing Serverless, the next generation of Cloud Computing Serverless as a new paradigm bypassing Infrastructure-as-a-Service and presenting a lightweight development concept to the developer community. A concept that makes it possible for small teams of developers to quickly develop substantial Cloud-based applications with a minimum amount of resources. The new lightweight programming paradigm promises to unleash a flurry of new lightweight apps that despite their ease of use can create serious applications.
Apache OpenWhisk, Open Source Project – In the second chapter, you got an introduction to Apache OpenWhisk, an open source, distributed Serverless platform that executes functions in response to events at any scale. OpenWhisk manages the infrastructure, servers, and scaling using Docker containers so you can focus on building amazing and efficient applications.
In the next three chapters, you did focus on Apache OpenWhisk: in Chapter 3, you learned about Apache OpenWhisk project. Then in Chapter 4, you found out on how to write your Hello World application with Apache OpenWhisk in Swift; and in Chapter 5, you had a Deep Dive into Apache OpenWhisk technology.
You were able to experience development of a Complete iOS app with Serverless Swift Backend in the complete iOS app using Serverless Swift.
Then you learned about eight popular Use Cases and you round it out with Cloud Native Best Practices.
When to use Serverless – Apache OpenWhisk – and when not to use it
Serverless computing has established itself as the go-to technology for building and running applications and services without having to concern oneself with managing servers. Serverless is an essential technology for pretty much all Cloud platforms that provide compute services and as such eliminates infrastructure and the myriad management and operational tasks associated with hardware and software servers in the Clouds that today cover the globe.
By establishing itself above the infrastructure, operating system, and language framework levels in the Cloud stack, serverless requires almost no management or operation of infrastructure from the application developer, enabling them to focus more narrowly on code, its quick and elastic deployment, and writing the custom business logic.
When to run workload on Serverless
Serverless runs code only on demand on a per-request basis, horizontally scaling transparently with the number of requests being served. In this manner, companies that utilize Serverless pay only for the resources necessary to complete actual tasks while knowing they will be used in the most efficient manner and never having to pay for idle capacity. For most applications running in the Cloud, this could end up being a very big savings indeed. For certain workloads, such as ones that require massive parallel processing, especially on an irregular basis, serverless can not only be faster but the cumulative cost-effectiveness could be enormous from traditional or dedicated alternatives.
When running Serverless is not practical
Long-running processes – FaaS and serverless workloads are designed to scale up and down perfectly in response to workload, offering significant cost savings for spiky workloads. But for workloads characterized by long-running processes, these same cost advantages are no longer present and managing a traditional server environment might be simpler and more cost-effective.
Vendor lock-in – Serverless architectures are designed to take advantage of an ecosystem of managed Cloud services and, in terms of architectural models, go the furthest to decouple a workload from something more portable, like a VM or a container. For some companies, deeply integrating with the native managed services of Cloud providers is where much of the value of Cloud can be found; for other organizations, these patterns represent material lock-in risks that need to be mitigated.
Patterns and antipatterns
In software engineering, a software design pattern is a known solution to a class of problems in programming. An antipattern is a pattern that may be commonly used, but it is ineffective and counterproductive in practice.
Function logic is stateless.
Functions are idempotent.
There is just one task per function.
Functions should finish as quickly as possible.
Recursion should be avoided.
You need to be aware of the concurrency problems with isolation and rate limits.
Functions should avoid opening or minimize external network connections.
The state is offloaded to an assumed Cloud storage.
Consuming simple APIs via HTTP requests
Fanning out the tasks into subtasks and fanning in the results from individual workers
Using API Gateway as a proxy to encapsulated atomic Serverless functions
Performing the gateway aggregation
Publish-subscribe services using messages
Queue-based load leveling
The strangler pattern – a way of migrating a legacy system step by step by replacing existing functionalities with new services and serverless functions
Read-intensive calls
For processing streams and pipelines from IoT sensors or web UI clickstreams
Assure clients are insensitive to function “cold-start” wait times.
Do not include custom logging or trace resources for problem determination – good serverless platforms provide logging for you automatically as well as audit services.
Do not do everything “from scratch” but leverage existing patterns and Cloud platform services.
Use consistent, non-colliding naming conventions for functions.
Utilize code source control systems and include code reviews and static analysis of the code. Also, add unit, function, and integration tests and execute them automatically at build time.
Do not go the way of recursion.
Look to use functions to tackle smaller, isolated parts when breaking down existing legacy applications while avoiding replacing stable centralized code.
Serverless benefits are still often misunderstood
What is often emphasized as the major advantage of serverless is that it is considerably cheaper to use than using infrastructure-based solutions. Many see serverless as a lightweight solution that can solve problems of a lightweight nature. But as we have demonstrated with use cases in this book, although the serverless architecture can be considered lightweight, it can easily handle any-size problems with major agglomeration of data every bit as large scale as the largest of the infrastructure-based use cases.1 In addition, Serverless application development platforms provide almost total visibility into system and execution times and can aggregate the information systematically.
The Serverless patterns listed earlier are key to learning serverless computing from the ground up. Rather than starting with concepts, you start with running code which, since it is often open source, you are free to tweak and modify as you see fit. This will speed up the development process and ramp up your application delivery significantly.
Sometimes you might need to run your own deployment of Serverless – Apache OpenWhisk – in the enterprise in order to take advantage of your own infrastructure that is managed by your own organization. This is often the case in many industries due to regulatory and security concerns or where Public Cloud SLAs fall short.
As examples, medical providers have to consider requirements like the privacy of the patient or governmental agencies the handling of sensitive documents (civic or military alike). In many cases, it is often impossible to use Public Cloud data centers.
Running your own serverless platform may not be so bad, since you have access to trusted and proven codebases like Apache OpenWhisk which gives you access to a community of development resources and skills available as good as any in the market. Plus, well-managed open source projects always leverage the latest and greatest technologies available and have strict governance to assure quick turnarounds on bug fixes and security updates. Since Apache OpenWhisk is an Apache Software Foundation’s Top-Level Project, you can be assured that it strives to be the best.
How to connect with authors and the technology
First of all, take part in the meetups that are being organized around the world. There are plenty of virtual meetups in the acceptable hours. Check all the world’s locations and the biggest groups for the interesting themes of serverless. One of those meetups (www.meetup.com/Serverless/) is a good way to establish contacts within the global Serverless community.
Also you might want to follow developments of the framework here: https://github.com/serverless-operations – this Serverless Framework gives you everything you need to develop, deploy, monitor, and secure serverless applications on any Cloud.
Finally, you can become a committer of Apache project – and contribute to Apache OpenWhisk – check details here: www.apache.org/dev/committers.html.
There are some project meetings recorded on the Apache OpenWhisk YouTube channel: www.youtube.com/channel/UCbzgShnQk8F43NKsvEYA1SA.
You might also want to get the badge on Serverless using Developing Serverless Applications: A Practical Introduction with Apache OpenWhisk from https://cognitiveclass.ai/courses: Serverless Computing using Cloud Functions – Developer 1 course.
Also there is a free book available for download on Apache OpenWhisk with Node.js by our colleague Raymond Camden: Developing Serverless Applications: A Practical Introduction with Apache OpenWhisk – find out about it here: www.raymondcamden.com/tags/openwhisk/.
There is another book covering couple of the angles of using Apache OpenWhisk: Learning Apache OpenWhisk: Developing Open Serverless Solutions 1st Edition by Michele Sciabarrà (www.amazon.com/Learning-Apache-OpenWhisk-Developing-Serverless/dp/1492046167) (nothing on Swift though).
Finally, check the GitHub repository of this book here for the updated open source code and additional examples and resources.
About the authors and how to contact them
Lennart and Marek gathered together about 60 years of IT professional industry experience. For both of them, IT and technology is a life passion. It even led Marek to found his own startup in robotics and brought Lennart to undertake early AI research in Silicon Valley. And Northern California is where most of the time you might be able to meet Lennart and Marek in person, as they often present at various conferences in the United States and join various user groups globally on a variety of topics. See Figure 9-1 for a picture from their event in San Francisco. Lennart and Marek can be also reached at @LFrantzell @bluMarekS on Twitter or via email: [email protected].
At a meetup in San Francisco, from right Lennart and Marek