今日推荐开源项目：《大叔流 ojichat》
今日推荐英文原文：《A Serverless Future》
今日推荐开源项目：《大叔流 ojichat》传送门：GitHub链接
推荐理由：虽然在我们的生活中并不多见，但是实际存在着的聊天流派——将表情和文字融为一体的全新语言，因其多见于大叔发过来的各种聊天消息中，故名为大叔流。这个项目就可以根据你提供的只言片语和设定生成大叔流的对话——尽管是日文的句子，很难用在我们的日常生活中。不过说到底，最好不要真的一次发这么多表情给别人就是了……
今日推荐英文原文：《A Serverless Future》作者：Bivás Biswas
原文链接：https://medium.com/@emailbivas/a-serverless-future-e0be190f1e66
推荐理由：无服务器指的是服务器由云提供商管理的情况，这篇文章则是介绍了无服务器的特点以及它会在未来改变什么
A Serverless Future
Serverless Computing is here and how to deal with it
Serverless doesn’t mean that there are no servers. It just means that the servers are managed by the cloud provider.Historically cloud providers like AWS, Google and Azure have given us servers to rent. We’d rent the servers, a process called provisioning, and then install our favorite OS and our tech stack along with our server program. We’d put the server in an autoscaling group behind a load balancer so when the demand increases, more servers can be automatically added to the server pool. When the demand dies down, the auto-scaling group would automatically release the servers so we don’t keep paying for them.
Let’s talk about the scaling aspect of things before we dive in serverless.
The property of the cloud to scale up or down based on need is also called Elastic. You’ll find this in words like AWS EC2 (Elastic Cloud Compute) or ELB (Elastic Load Balancer), EB (Elastic Beanstalk), etc.
Elasticity comes with a cost. The auto-scaling group needs to be configured. This means you’d need to know how auto scalers work. While this is not a big deal compared to having to maintain an IT department in your office to maintain your servers, it does require the developer to learn cloud-specific skills.
The cloud-specific skills that are replacing the hardware engineers fall under the umbrella of dev-ops- a field that combines development and hardware/network/server operations.
DevOps is quickly becoming the operational standard for how tech companies deliver software.
Instead of developers learning backend operations, a developer might ask what if they could run their code on the cloud without needing to worry about provisioning a server and configuring it and then deploying their code to be able to run. What if they could just hand over the code to AWS or GCP or Azure and ask them to auto-configure the entire backend with scaling so the code could just run without the developer needing to learn a whole bunch of backend server ops.
This wish partly came true in the form of the serverless architecture and it brought with it a lot of promises as well as a new set of challenges. We’ll talk about those next.
The Promises
In a serverless architecture, the entire compute stack is managed by the cloud provider. Backend-as-a-Service (Baas) as opposed to IAAS (Infrastructure-as-a-Service). Running your app without managing infrastructure. It’s a pay-per-use model. Like taking an Uber and not having to rent a car.The serverless architecture on AWS is called AWS Lambda. Serverless is also known as Function-As-A-Service (FAAS) and that’s why serverless on Google is called Google Cloud Functions, and Azure Functions on Microsoft’s Cloud.
The Challenges
The challenges came in the form of having to give up control of the local development environment. There is no more running the code on your PC first and then handing it off to the Ops team for them to provision infrastructure and deploy your code.Since your code now relies on other APIs or functions, you’ll need to provision the infrastructure on the cloud to run those dependencies to be able to run your code. There is no more line by line debugging in your PC. Debugging is now message based and is more complicated and time-consuming.
This can be a good thing if you think of it as having accountability towards deployment from day 1 but otherwise, it is just a pain for all the traditional developers who have for years relied on a particular dev environment.
In a way, developers will now need to take on more an Ops team approach from the beginning. Since cost is based on per invocation of the function, developers will need to start thinking about the memory requirements for their functions, memory optimizations and the operational aspects of running their functions on the cloud. We’ll talk about this next.
Operational and Financial Metrics
Most apps today have 2 components. Connections to 3rd party APIs for everything ranging from User Management (Auth0) to payment processing (Stripe) and the business logic of the product itself i.e. it’s own functions.The final cost is based on per invocation of a function which is how long the function takes to complete and how much memory it consumes. The cost of running these apps on serverless, therefore, depends on 2 factors — the amount of time waiting for API calls and the amount of time running the business logic.
We don’t have any control over how long a 3rd party API call might take to return a result so it's prudent to keep an eye on the latency of different APIs while designing the serverless app.
We have control over our own business logic. To be able to optimize the cost of running the business logic, developers will need to engage the cloud metrics provided by the cloud provider. AWS provides CloudWatch which gives out information like memory usage, compute times, API wait times, etc.
There are two things that developers can control while configuring a serverless app.
- The amount of memory allocated and
- The function time out.
The amount of memory
Developers will need to plan for capacity from day 1. Since cost is based on memory, choosing the right amount of memory needed to run the function is an important step in optimizing the cost. The other aspect of cost optimization and capacity planning is to optimize the code so it takes less memory to run.The function time out
Since cost is also based on the execution time of the function, programming a time-out is essential. Otherwise, if a 3rd party API call hangs, then your function will keep on waiting for a response and you’ll be paying for it.Besides the Ops and financial planning, developers will also need to be planning for security from day 1. As I mentioned earlier, to run your functions you’ll need to provision the infrastructure on which your function depends on. This means that access policies will need to be set.
In the traditional pipeline of code development, security usually comes at the last stage in the pipeline. You hand your code to the network and security team. They’ll send back notes on what to do to make the code fully compliant. The team would go through a few iterations at that time looping back and forth between the security team and dev team. With serverless, the conversation about security has to happen continually during development.
Pros and Cons of Serverless
The main advantages of Serverless Architecture are -- Reduced Cost
- No Server Maintenance and Configurations
- Cold Start.
- Reliance on 3rd party Vendors
1. Lower Cost
There is a cost involved in provisioning servers. Many companies that need a large number of servers for a short amount of time usually do a spot bidding on these servers on AWS to minimize cost. Even though the servers spin up or down according to demand, there is a minimal cost to maintain a minimum amount of servers so the backend is available at all times.With serverless, the servers spin up only when the app needs to run. So you literally pay for the amount of time your app runs.
Serverless is a relatively new thing and companies and people who have embraced it are reporting much lower operating costs.
Coca-cola went from $13000 per year to $4490 per year after switching to serverlessCoca Cola’s story is available here.
2. No Server Maintenance and Configurations
The main advantage of serverless is that the DevOps team doesn’t need to worry about provisioning the backend infrastructure.Provisioning the backend infrastructure has nothing to do with the business model of a company.
Any amount of time that can be cut down from managing OS versions, installing updates, updating database systems, managing database licenses, patching, etc can be put towards managing the product and focusing on optimizing the Ops, financial and security aspects of the company’s product.
Let’s touch on the disadvantages of serverless.
- Cold Start.
- Reliance on 3rd party Vendors
Sure, having to keep an eye on operational challenges and financial and security metrics while developing code is a whole new set of complications to embrace. But these can be seen as a blessing or a curse. Besides the soft challenges, there are some hard drawbacks of serverless. We’ll talk about those next.
1. Cold Start
The cloud providers will spin the servers down when not in use for about 40–60 minutes. It takes time (30 seconds to a minute) to bring the servers back up. This introduces latency in the system for the first invocation.Companies should aim to avoid their customers being exposed to this latency. Imagine opening up an app and having to wait before the app starts working. Of course, the 2nd user that jump in will now enjoy the server instantly but the ‘warm-up’ has cost you the first user.
One way to avoid this is to be able to predict when the users will start coming in. If you’re expecting a surge in business then you can make some API calls yourself from the business to warm up the servers. For enterprise systems, this is not possible for one person to do. Companies will need to build out automated agents for this job that will get triggered automatically by the prediction module.
This can get complicated for complex workflows and can be a deciding factor between going serverless or not at this time.
Another disadvantage of serverless is the heavy dependency on 3rd party providers.
2. Reliance on 3rd party Vendors
A major drawback on not having your own servers, and relying on 3rd party APIs for everything is that now you’re bound to everybody’s terms and conditions. API economy is a real thing. Companies are in the business of providing API services. They all have their rate limit caps and number of requests that can be made within a particular timeframe.Developers enjoy all of the benefits of auto-scaling on the cloud with serverless but they’ll still need to have the conversation with the 3rd party vendors about the price tier that they’re signing up for.
This means your serverless can scale with your users on your end but that may not mean that you’re signed up to scale like that with your 3rd party vendor.
You can end up paying surge prices for over the limit call volumes and that can get expensive.
On the other hand, if you did sign up for a higher tier in anticipation of a surge then you’re paying the 3rd party API vendor while waiting for that surge. Sounds familiar? Isn’t that why we got so excited about getting away from EC2 in the first place- so that we didn’t have to pay for sitting around maintaining the servers?
The cost has shifted from paying the cloud provider to paying the 3rd party vendors. This for the most part, as we saw in the example of Coca Cola comes out cheaper but for some use cases, it may not.
In Summary
While the cloud disrupted the traditional IT department of a company, serverless disrupts the model of hiring many different specialists in the software pipeline to be able to realize the software.Just like the advent of digital filmmaking phased out the job of the traditional editor who only knew how to edit. Digital filmmaking brought in the guy who knows how to edit, color grade, apply basic vfx and work with green screens, titling, sync sound, do some prelim sound pass, etc.
Similarly, the advent of serverless is starting to phase out the traditional developer who only knows how to write code.
More and more job postings today are about the guy who not only knows how to code but architect a system, be a database admin, know about security and networking, can perform operational functions like provision infrastructure, deploy continuous integration and continuous deployment (CI/CD), etc.
This guy is hard to find but this guy is in demand. We know them today by the name of DevOps Engineer who can also do serverless. With serverless, DevOps engineer will be replaced by one guy — The Cloud Engineer.
下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/
