Source | Serverless Official Account; Author | Ben Kehoe; Translator | donghui
Function is not the point
If you choose Serverless because you like Lambda, you are doing it for the wrong reason. If you choose Serverless, it is because you like FaaS, and you are doing it for the wrong reason. Function is not the point.
Of course, I like Lambda-but this is not why I advocate Serverless.
Don't get me wrong, the function is good. They allow you to scale transparently, you don't have to manage the runtime, and they are naturally suitable for event-driven architectures. These are very useful features.
But the function should eventually become a small part of the overall solution. You should use functions that contain business logic as the glue between hosting services that provide most of the heavy lifting that constitutes the application.
Custody service is not the point
We are fortunate that the cloud provider can provide such a wide range of hosting services for many different parts of the application. Database, identity and access management (I’m so glad I don’t have to own it!), analytics, machine learning, content distribution, message queues, and other different models.
The hosting service provides the functions you need with less trouble. You don't have to patch the servers they run. You don't have to make sure that auto-scaling correctly provides the required throughput without a lot of free capacity.
Managed service significantly reduces your operation and maintenance burden. Hosting services are great-but... they are not the point.
Operation and maintenance is not the point
It's nice to know that you can use less operation and maintenance resources to keep the application healthy. It is especially important that the resources you need are mainly based on the number of functions you provide rather than traffic.
Reduce operation and maintenance, more efficiency-but... this is not the point.
Cost is not the point
Well, sometimes all companies want you to do is reduce costs-and this is what you care about. Serverless will help you do this. But in general, cloud computing bills are not the focus of the problem.
Your cloud bill is only one component of the total cost of a cloud application. First, it is the salary of operation and maintenance personnel-if your operation and maintenance personnel resources are less, the cost will be lower. And your development cost.
There are many cost advantages here-but... these are not the points.
Code is not the point
The code is not only not the point, but also a responsibility. The code can only do what you want. Bugs will weaken this. You will only lose focus by writing more code. The more code you have, the more opportunities you have to deviate from your expected value. Understand that this is a cultural shift.
Technology has always been difficult. Smart people create value through technology. So developers began to believe that smartness is inherent and good. It took us so long to make Swiss watches that we did not realize the appearance of the quartz Casio and accused this evolution of lacking elegance.
We need to understand and solve business problems instead of using our ingenuity to solve technical problems. When you have to code, you are solving technical problems.
Technology is not the point
The reason we do this is to achieve certain business goals. The business value your organization is trying to create is the focus.
Now, sometimes, you are selling technology. But even if your product is technology, it may not be the value of the product you sell.
There is an old saying that people buy holes instead of drills. When you need to drill a hole in the wall, you don't care how beautiful the drill is. You only care how well you drill to get the hole you need.
At iRobot, we do not sell robots. We don’t even sell vacuum cleaners. We sell clean houses. Roomba gives you time to return to your daily life to focus on the things that are important to you. So, if technology is not the focus, what are we here for?
The point is focus
Serverless is a method that focuses on business value.
How can functions help you deliver value? They let you focus on writing business logic instead of writing supporting infrastructure for business logic.
Managed services allow you to focus on writing functions. Fewer operation and maintenance resources can free up manpower and funds to create new value for customers.
Observability provides you with tools to deal with MTBF and MTTR, both of which can measure how often your customers get value. Spending less money on cloud computing means you can spend more directly on supporting value creation.
Focus is the reason for choosing Serverless
You should choose Serverless because you want to focus on creating value-in your company, you strive to apply technology to create business value.
Going back to cost, Lyft's AWS bill, $100 million per year, has recently become news. Many people chime in that they can do it cheaper-they can't, but this is not the point.
If Lyft switched to Lambda and managed the service as much as possible, would their bills be lower? Maybe. But when they take the time to restructure, what use will it do? They lose focus.
The company is at a stage where development is more important than cost control. Eventually, this situation may change. Listed companies are accountable to shareholders, so reducing costs can bring them value. But for Lyft today, providing value to their customers means executing their current applications and processes. They are making a serverless choice.
What I want to tell you is that Serverless has never involved the technology we call Serverless. So what does our so-called serverless technology have to do with it?
Serverless is the result of focusing on business value
Technology is the result of how you deliver value. The development team and the operation and maintenance team are traditionally separated because they have different focus points. But we see that this trend is changing.
The traditional model focuses on technology-development technology vs operation and maintenance technology. But we have seen people realize that the focus should be on value-the features delivered, including how to build and run.
When we adopt this concept of focusing on business value and run its logical conclusions, we get Serverless.
When you want to focus on delivering value, you want to write functions. When a function needs state, it needs a database. To get it from others, you can use DBaaS-you can choose between your options based on how much it keeps you focused.
When choosing hosting services, some of them may even be user-oriented. If you can log in using a social account instead of having your own account, then you have one less thing to manage and less of the chips you have for the user experience.
Now, you still have responsibility for everything you outsource. Your users don’t care that their bad experience is caused by a third party. This is still your problem. You need to leave the interruption to your users while accepting that you cannot fully control your fate there. This is an uncomfortable place, but it is worth it.
You can't win points in these things-but you can lose. This means you need to know what "bad" looks like. This requires you to have sufficient knowledge of the outsourcing products and technologies to ensure that you provide users with sufficient quality.
Please note that having in-depth expertise in one focus area and broad but weak knowledge in adjacent areas is very similar to the concept of T-skills—applicable to organizations and teams.
Serverless is a trait
Serverless is a characteristic of the company. If a company decides that it should not have core technologies that are not realizing its business value, then it is serverless. Few companies are completely serverless. But within the company, there can still be a serverless part.
If your team decides to focus only on the value it delivers, and delegate anything beyond those values to another team, or ideally to the outside—then your team will become serverless. You can't always choose to use external technology-this is good, you can still make the best choice under limited conditions.
In a large enough organization, it is no longer important. When Amazon.com uses Lambda, it is completely serverless, although it is on-prem in a sense. But what if you are the only one?
What if you are excited about Serverless, but feel completely alone in the company? If you are far from the actual business value-what if you patch a team that serves the creation of user-oriented content ? I want to convince you that you can become Serverless in any situation today.
Serverless is the direction, not the end
I used to discuss serverless technology as a spectrum, because I know that there is no clear line to distinguish between serverless technology and non-serverless technology. I mean, there is hardly a bright line to separate any given grouping, so I am safe in this assumption.
I have talked about things like Kinesis that need to manage fragments. It is serverless, but it is less serverless than SQS. You don't need to use RDS to patch the instance, but you need to choose the instance type and number. These technologies are serverless in varying degrees.
But recently I started to realize that one problem with describing Serverless as a spectrum is that it does not mean mobile. Just because you are using a certain product designated as Serverless does not mean that you should feel that you have acquired Serverless-it is acceptable to continue using it and think that you have checked the Serverless checkbox.
Climb the serverless ladder
I began to think of Serverless as a ***. You are climbing a certain nirvana where you can deliver pure business value without overhead. But each step on the ladder is a valid serverless step.
If you move from on-prem to public cloud, it is a ladder. If you migrate from a virtual machine to a container, it is simply a ladder. If you migrate to Kubernetes from no container orchestration or custom orchestration, this is the ladder. If you move from a long-running server to a self-hosted FaaS, it will be a ladder. But there is always a rung above you, and you should always keep climbing.
One thing that "ladder" does not convey is that it is not linear. Migrating from virtual machines to containers to Kubernetes are all steps up the ladder, but the same is true for migrating virtual machines from on-premises to the cloud. In these cases, there is usually no clear "better".
I thought of the analogy of many paths to the top of the mountain, but what I like about *** is that it can be infinite. There is no final state. I like Lambda, but I am always looking for a better way to deliver code that makes me pay more attention to value.
Serverless is a state of mind
Serverless is about how you make decisions, not your choice. Every decision is bound. However, if you know the right direction, even if you can't move directly in this way, you can choose the most closely integrated option and then move up another rung. So, how do you adopt this way of thinking? How do you make a serverless choice?
Configuration is your friend
I think many developers look down on configuration and think it is "not real programming". There is now a blind worship of programming. We were told that "software is eating the world", but we incorrectly translated it as "coding is eating the world."
We have believed that developers are the only important people in the organization, and our productivity awareness is the only important thing. We want to feel in the area, and this is what the code provides. Any obstacles in this area are detrimental to the business. We don't have any feelings about whether entering the area is really faster and creating value better than alternative routes.
Remember: days of programming can save hours of configuration
The constraints are good. The delete option can help you stay focused. Obviously, not all constraints are good-but generally speaking, the ability to do general things comes at the cost of taking longer to do a particular thing. The guardrail may wear out, but you will run faster than staring at the edge of the guardrail.
In this way, Serverless is about minimalism. Eliminate interference. Marie Kondo is big now, and the same advice applies. Look for components in your stack that will not generate value.
Fear of huge events that might happen
Possibility contains hidden complexity. For any technology, one of my main evaluation indicators is how much it has beyond the task at hand. When there is a lot of extra space, unnecessary complexity is dealt with and learned.
People tout Kubernetes as a single tool for every cloud requirement-it does! But if everything is possible, everything is possible. For a given task, Kubernetes can make mistakes because you don't consider how it behaves when it is not related to the task.
On the other hand, when you consider serverless services, you may have to choose between 80% of the solutions provided by major providers or services provided by third-party providers that better suit your needs. But what are the operation and maintenance requirements of this new provider? What is authentication like? These are hidden complexity, you need to introduce these features, you need to weigh the differences in these features.
Accept the discomfort of not owning your own destiny
When you use hosting services, provider interruptions can bring pressure. You cannot solve their problems. This is unavoidable-it always feels bad. You might think, "If I run my own Kafka cluster instead of Kinesis, I can find the problem and solve it". This may be true, but you should remember two things:
- That would distract people from creating business value.
- You will almost certainly do worse at running it. You will encounter more and worse things. The life goal of service providers is to be good at this-they have economies of scale, and you don't.
It can be difficult to go beyond the "I can always build it myself" attitude. Jared Short recently provided an excellent set of guidelines for selecting technology.
_My thinking about serverless
these days is in order of consideration. – If the platform owns, please use – If the market owns, please buy – If you can reconsider the demand, please execute – If you must build, please own. ——@ShortJared
Therefore, if you are using a cloud platform, please stay in the ecosystem as much as possible. In this way, you can eliminate many possibilities from the equation. However, if you can’t get what you need on the platform, please buy it elsewhere.
If you can’t buy exactly what you need, can you rethink what you’re doing to accommodate what you can buy? This is really important. It has reached the core of time to market.
If you have something that you think is valuable, you will want to ship it as soon as possible. But it’s better to ship something faster than build it precisely, because you don’t know if it’s the right thing.
Not only will it take longer to wait for the right thing to be built, but subsequent iterations will also be slower-and maintaining it will take up resources you can use to ship more things in the future. This applies even when the technology is not serverless: always ask whether adjustments to your requirements can achieve faster, better or more focused value delivery.
But in the end, if you must build it, own it. Find a way to make it unique. Now, this does not mean that everything you have built should become differentiated. In a perfect world, only see what you can’t buy. Imagine what a fully serverless greenfield implementation would look like, and find what needs to be built there.
Find the value part of your business
Therefore, fundamentally, you want to find the value part of your business. What technical job do you serve? Maybe you are a far cry from user-oriented products. You may only contribute a small part. But it is there, you can find it-and focus on this value.
Start with the direct value you provide to others in the organization and focus on that. Then start tracking the value chain. Make sure that all decisions are centered around the value you create. Make the serverless choice.
Hire people who can do the work automatically, and then continue to provide them with work. ——@Jessfraz
I like what Jessie Frazelle said. You can turn it around: automate the work and continue to do the required work.
Remember, you are not a tool. For any value you want to create, please create it automatically. If you manage build servers, find ways to make them self-service, so you are not delivering the build itself, but the build tools so that the team can deliver the build themselves.
Summary: Serverless is a state of mind
The focus is not on functions, managed services, operations, cost, code or technology. The point is focus-this is the reason for choosing Serverless.
Serverless is the result of focusing on business value. This is a trait. This is the direction, not the end. Climb the never-ending serverless ladder.
Configuration is your friend. Several days of programming time can save hours of configuration time. Fear of huge events that might happen. Accept the discomfort of not owning your own destiny.
Find the value part of your business and realize the Serverless status.
English original link:https://read.acloud.guru/serverless-is-a-state-of-mind-717ef2088b42