服务器开发和服务器应用开发
无服务器讲故事 (Serverless story-telling)
In my previous articles on serverless, I used themes such as cooking, growing, fishing, and hiring. In this, I talk about football, movies, and music. “What do they have to do with serverless?”, you might ask. Well, there isn’t anything directly common between these themes and serverless. However, with some imagination and story-telling, we can easily build the connections ourselves.
在我以前关于无服务器的文章中，我使用了诸如烹饪 ， 种植 ， 捕鱼和雇用等主题 。 在这里，我谈论足球，电影和音乐。 您可能会问：“他们与无服务器有什么关系？”。 好吧，这些主题与无服务器之间没有直接的共同点。 但是，通过一些想象力和讲故事，我们可以轻松地自己建立联系。
I often make analogies to convey the serverless message. Serverless adoption happens at different levels, not just at the core technical level. Therefore, why not add a bit of fun, mix it up with some variety, throw in a few fresh ideas, provoke your thoughts, and above all, relieve you from the serverless overdose!
我经常做出类比来传达无服务器消息。 无服务器采用采用的级别不同，而不仅仅是核心技术级别。 因此，为什么不添加一点乐趣，将其与各种变化混合起来，提出一些新的想法，激起您的想法，最重要的是，让您摆脱无服务器的过量使用！
This is a two-part write-up on how to approach your serverless development. In this first part, I talk about the set-piece concept and discuss how it might help to tune your serverless mindset. In the next part, I will walk you through a real use case and explain how to apply the set-piece thinking in serverless development.
这是关于如何进行无服务器开发的两部分文章。 在第一部分中，我讨论了机顶盒概念，并讨论了它可能如何帮助您调整无服务器思维方式。 在下一部分中，我将引导您完成一个实际的用例，并说明如何将无所不包的思想应用到无服务器开发中。
Ok, let’s start…
好吧，让我们开始...
山到mole陵 (Mountain to molehills)
It was the time when I got to know and fell in love with serverless. Around the same time, the daunting task of migrating a monolith eCommerce application to microservices also began.
那时我开始了解并爱上了无服务器。 大约在同一时间，将庞大的电子商务应用程序迁移到微服务的艰巨任务也开始了。
Monolith to microservices migration is probably one of the most popular conference talks of recent years. Reading anything on that gives you more thrills than a crime novel. But the moment you sit down and start to think about moving your monolith mountain into molehills of microservices, that’s when the reality strikes and the panic sets in. If you then decide to also carve those molehills out of serverless, the picture of a bull in a china shop is likely to flash through your mind!
从单片到微服务的迁移可能是近年来最受欢迎的会议演讲之一。 读任何东西都比犯罪小说给你更多的刺激。 但是，你坐下来开始思考移动你的巨石山到微服务的molehills的时刻，那就是当现实罢工以及紧急集合。如果你再决定也能开那些molehills了无服务器的， 牛市中的图片一家中国商店可能会在您的脑海中闪过！
改变我思想的“目标” (The ‘goal’ that changed my thinking)
One day, with my mind filled with serverless and the migration task ahead, I sat down to watch a football match (English football, aka soccer). Eyes were on the TV, but my mind was in the clouds.
有一天，我的脑海里充满了无服务器的工作和迁移的任务，我坐下来观看一场足球比赛(英式橄榄球，又名足球)。 眼睛在电视上，但我的脑海在云端。
I got distracted when the host team scored a goal. The goal was scored from a free-kick. Commentators were bragging about the goal and how good the team was in set-piece play.
当东道主打进一球时，我分心了。 进球来自任意球。 评论员们吹嘘的目标，并有多好，球队在定位球打法。
Though I knew the term set-piece before, I never thought through it beyond a goal-scoring context. Here is the football definition of the set-piece.
尽管我以前曾知道“ 计件制 ”一词，但我从来没有想过进球得分的概念。 这是套装的足球定义。
The term ‘set-piece’ refers to a situation when the ball is returned to open play following a stoppage. Many goals result from set-piece play. Thus, set-piece play is an important skill, and players spend much time practicing. Set pieces are one area where tactics and routines can be worked out in training in advance of matches.
术语“ 固定件” 是指停球后球恢复开放比赛的情况。 组合比赛可带来许多进球。 因此，散打游戏是一项重要技能，玩家需要花费大量时间进行练习。 固定装置是一个可以在比赛前训练中制定战术和例行程序的区域。
An idea around the set-piece play sparked in my mind, but I needed more use cases than just football to develop my thinking. Further exploration revealed that the set-piece terminology is also common in film making, theater, and music.
围绕定位球发挥的想法在我的脑海里引发的，但我需要更多的用例不仅仅是足球培养了我的思维。 进一步的研究表明，固定装置术语在电影制作，戏剧和音乐中也很常见。
电影制作中的配件 (Set-piece in film making)
Here is an abstract set-piece definition from the film industry.
这是电影业的抽象布景定义。
‘Set-piece’ is a scene or sequence of scenes whose execution requires complex logistical planning. Often, screenplays are written around a list of such set pieces. Set pieces are planned using storyboards and rehearsals. … different groups of people will work on different set pieces individually.
“布景”是一个场景或一系列场景，其执行需要复杂的后勤计划。 通常，剧本是围绕这样的布景清单来写的。 使用情节提要和排练来计划布景。 ……不同的人将分别处理不同的场景。
音乐创作中的装置 (Set-piece in music composing)
Many composers follow the set-piece concept while composing music. The process starts off with individual music parts, where the notes are written first, rehearsed, recorded, and then edited together as one.
许多作曲家在作曲时都遵循组合乐的概念。 该过程从单独的音乐声部开始，首先将音符写入，排练，录制，然后一起编辑。
I am sure there are so many experiences in life that resemble the above, the so-called set-piece experience!
我敢肯定，生活中有很多与上述相似的经历，即所谓的固定经历！
The more I studied, the more refined my thoughts became. This helped me to identify 5 distinctive characteristics of a set-piece from the above contexts.
我学习的越多，我的想法就越精致。 这帮助我从以上背景中确定了套装的5个鲜明特征。
机件特征 (Set-piece characteristics)
1. Focus is on the part
1.重点在于
2. Planning and practice make things perfect
2.计划和实践使事情变得完美
3. Rehearsing at the practice ground takes it closer to the main stage
3.在练习场进行排练可以使其更接近主舞台
4. Different sets of people work on different set-pieces
4.不同的人在不同的零件上工作
5. All the pieces together make the whole
5.所有部分共同构成整体
1.重点在于 (1. Focus is on the part)
Even though the vision is to win the match or complete the entire movie, they focus on a part or a scene to get that piece done to perfection. This is how I developed the concept of the “Visualize big but focus small” mantra that I often talk about.
即使他们的目标是赢得比赛或完成整部电影，但他们还是专注于某个部分或某个场景，以使作品完美无缺。 这就是我经常谈到的“ 大可视化但小聚焦 ”口头禅的概念。
2.计划和实践使事情变得完美 (2. Planning and practice make things perfect)
Set-piece play on a football pitch requires clear planning. This includes the players, their position, the angle, the target, and the execution. When it comes to movie making, each set-piece scene requires careful and often complex planning. What this teaches us is that, even though we focus on a subset, the preparation of that piece plays an important role towards its perfection.
在足球场上进行固定比赛需要明确的计划。 这包括玩家，他们的位置，角度，目标和执行力。 对于电影制作，每个场景场景都需要仔细且往往是复杂的计划。 这告诉我们的是，即使我们专注于子集，该作品的准备工作也对其完善起着重要作用。
3.在练习场进行排练可以使其更接近主舞台 (3. Rehearsing at the practice ground takes it closer to the main stage)
It is common in many sports that the teams go through their practice routines up to the main event. This helps them adjust their tactics, tune their movements, and effortlessly carry those into the big match.
在很多运动项目中，团队通常都要按照惯例进行练习，直到主要比赛。 这有助于他们调整战术，调整动作并毫不费力地将其带入大赛。
This is also the case in film making. Artists spend several days at the rehearsal studio before the final shoot.
电影制作中也是如此。 在最后拍摄之前，艺术家们在彩排工作室里呆了几天。
4.不同的人在不同的零件上工作 (4. Different sets of people work on different set-pieces)
In football, certain play styles suit certain players. In films, certain scenes are ideal for certain artists. Identifying the needs of each part and associating the right personnel is important for its success.
在足球比赛中，某些比赛风格适合某些球员。 在电影中，某些场景是某些艺术家的理想选择。 确定每个部分的需求并与合适的人员联系对于其成功很重要。
5.所有部分共同构成整体 (5. All the pieces together make the whole)
Though I’ve been focusing on the parts, all the pieces must come together for a match or a movie. The glue that makes this happen differs. In football, it is the play system — the faults, the stoppage, and the rules. For a movie, it is the editing, the background score, and the voice recording that stitches the pieces together.
尽管我一直专注于各个部分，但所有部分都必须组合在一起才能进行比赛或电影。 造成这种情况的原因不同。 在足球比赛中，它是比赛系统-错误，停工和规则。 对于电影，是剪辑，背景乐谱和语音记录将片段拼接在一起。
Let me take a brief pause here before translating the above set-piece characteristics into serverless realization.
让我在这里稍作停留，然后再将以上设置的特性转换为无服务器实现。
Why am I focusing on such simple things for so long? How do they fit within the frontiers of serverless?
为什么我这么长时间专注于这些简单的事情？ 它们如何适合无服务器领域？
Well, inspirations are all around us. Even the simplest of things in life can inspire us. When inspiration and the imagination magically come together, the result can be awesomely pleasing!
好吧，灵感无处不在。 即使是生活中最简单的事物也可以启发我们。 当灵感和想象力神奇地融合在一起时，其结果将令人赞叹不已！
Pleasing is one thing; becoming purposeful is a completely different matter. Part of my ambition here is to make it purposeful.
取悦是一回事； 有目的性是完全不同的事情。 我在这里的野心的一部分是使它有目的。
I am here to convey my thoughts and the practices from my experience. You don’t need to be a football fan, movie-goer, or a music lover. I will keep it simple with no software jargon, principles, or theorems.
我在这里传达我的想法和实践经验。 您无需成为足球迷，看电影的人或音乐爱好者。 我将保持简单，没有软件术语，原理或定理。
Here are the few observations that pushed me towards this analogy to connect it with serverless.
以下是一些使我趋向于将其与无服务器连接的类比的观察结果。
不同的路径。 一个目的地 (Different paths. One destination)
The journey to serverless is different for each one of us. For some, it could be an easy transition from past experience. For others, it requires further learning. Not everyone carries the same technical background or the skills to become instantly successful. Hence, simple inspirations may help to find some purpose in our thinking as we get closer to serverless.
对于我们每个人来说，无服务器之旅都是不同的。 对于某些人来说，这可能是从过去的经验轻松过渡的结果。 对于其他人，则需要进一步学习。 并非每个人都有相同的技术背景或技能来立即取得成功。 因此，随着我们越来越接近无服务器，简单的灵感可能有助于在我们的思维中找到目标。
一心一意。 两个想法 (One mind. Two thoughts)
You must have heard many times that serverless requires a different mindset. It becomes quite evident when you look at the technologies associated with serverless.
您肯定已经多次听到无服务器需要不同的心态 。 当您查看与无服务器相关的技术时，这一点变得非常明显。
Along with the initial mindset, serverless requires a change of thinking on how we develop applications. This is different from the traditional developmental approaches you may be familiar with. I often refer to this as the mind-shift.
除了最初的想法，无服务器还要求改变我们如何开发应用程序的思路。 这与您可能熟悉的传统开发方法不同。 我经常把这称为思想转变 。
想大点。 练习小 (Think big. Practice small)
This has been said many times in many ways. Engineers who do not have the exposure to microservices or the incremental developmental practices may find it difficult to grasp certain aspects of serverless development. Hence, it is important to start them on their journey with small projects to help grow in confidence and remind them that any complex problem can be tackled bit by bit.
这已经以许多方式多次被提及。 没有微服务或增量开发实践经验的工程师可能会发现难以掌握无服务器开发的某些方面。 因此，重要的是从小项目开始他们的旅程，以帮助他们建立信心，并提醒他们任何复杂的问题都可以一点一点地解决。
可怕的名字。 简单的技术 (Scary names. Simple technology)
I once had a conversation with an engineer. I suggested writing a lambda function to solve a particular problem. Even though they’d been programming for a while, they panicked. “Ooh, I haven’t done anything of that sort, so I’m not sure!”, was their reply. My response was to think of it just like a function!
我曾经与工程师交谈。 我建议编写一个lambda函数来解决特定问题。 即使他们已经编程了一段时间，他们还是感到恐慌。 “哦，我还没有做任何这样的事情，所以我不确定！”，是他们的回答。 我的React是将其视为一个函数！
SQS is just a queue. SNS is just a topic. EventBridge is just an event bus. S3 is just a data store. I can go on and on. These are the strange names people hear when they start with serverless. The moment you describe what these services are using common terminology, the conversation becomes much easier!
SQS只是一个队列。 SNS只是一个话题。 EventBridge只是事件总线。 S3只是一个数据存储。 我可以继续下去。 这些是人们从无服务器开始时听到的奇怪名称。 当您使用通用术语描述这些服务的含义时，对话将变得更加容易！
早日成功。 无限可能！ (Early success. Endless possibilities!)
When I first moved to Java after developing many years in C and C++, I felt the change. The entire ecosystem around Java just expanded and brought everyone more opportunities. The myth of distributed computing was busted and brought it closer to our doorsteps.
在用C和C ++进行了多年开发之后，我第一次迁移到Java时，我感到了改变。 围绕Java的整个生态系统刚刚扩展，并为每个人带来了更多机会。 分布式计算的神话破灭，使它更接近我们的家门口。
Similar to the above but in a different way, I see the entire serverless spectrum bringing us opportunities at cloud-scale. The initial success you experience with serverless is crucial. It acts as the springboard for further victories. Hence, my advice to keep things simple in order to make a winning start.
与上述类似，但以不同的方式，我看到整个无服务器频谱为我们带来了云规模的机会。 您在无服务器环境中获得的初步成功至关重要。 它充当了进一步胜利的跳板。 因此，我的建议是保持简单，以赢得成功。
It is easier to climb a molehill than to conquer a mountain!
爬小丘比征服山容易！
将设定思维转移到无服务器 (Transporting the set-piece thinking into serverless)
1.重点在于 (1. Focus is on the part)
A monolith application is often viewed as a scary monster. Though it may look impossible to break a monolith into parts, there are always ways to view it as a combination of logical parts.
整体应用程序通常被视为可怕的怪物。 尽管看起来似乎不可能将整体分解为多个部分，但是总有办法将其视为逻辑部分的组合。
If you are familiar with the terminologies such as domains, components, modules, subsystems, and packages, then these can help with your thinking. Here are few initial ideas to assist you in identifying the parts.
如果您熟悉诸如域，组件，模块，子系统和软件包之类的术语，那么这些将有助于您的思考。 这里有一些初步的想法可以帮助您识别零件。
Look for logical grouping of functionality. For example, in the following diagram, the User admin is for validating the user identity, checking the user permissions, and establishing a user session.
寻找功能的逻辑分组。 例如，在下图中， 用户admin用于验证用户身份，检查用户权限并建立用户会话。
Identify features that are not related. A background task such as Reports generation may not have anything in common with, say, the User admin.
识别不相关的功能。 诸如报告生成之类的后台任务可能与User admin没有任何共同点。
Identify dependent functionalities that do not belong in the same group. Both Fraud check and Payment authorization are required to complete a payment request, but they don’t belong in the same group. Payment authorization uses the service offered by the Fraud check.
确定不属于同一组的相关功能。 欺诈检查和付款授权都需要完成付款请求，但它们不属于同一组。 付款授权使用欺诈支票提供的服务。
Separate the features that act on-demand. For example, a successful Payment authorization and other internal state changes may trigger the Settlement to initiate a fund capturing process.
分离按需运行的功能。 例如，成功的付款授权和其他内部状态更改可能会触发和解，以启动资金收集流程。
The above example depicts some of the parts of a Payment System. If we view it from a level above, the Payment System itself could be a part of a bigger enterprise application.
上面的示例描述了支付系统的某些部分。 如果从更高的角度来看，支付系统本身可能是更大的企业应用程序的一部分。
Once you have identified some logical groupings, treat each of them as a monolith and try to break them into further pieces. Don’t get constrained by what a microservices text book says or the definition of a domain is. At this stage, what you are interested in is finding the pieces. Big or small, simply does not matter.
一旦确定了一些逻辑分组，就将每个逻辑分组视为一个整体，并尝试将其分解为更多部分。 不要被微服务教科书所说的或域的定义所束缚。 在此阶段，您感兴趣的是找到碎片。 大或小，根本无所谓。
I often talk about the cosmos analogy. The cosmos as a whole is difficult to comprehend. But, if you focus on a distant orange dot, you will find a galaxy behind it. You explore the galaxy to see the stars. You observe a star to discover its planets and their moons. You keep going until you find you and me somewhere!
我经常谈论宇宙的比喻。 整个宇宙很难理解。 但是，如果您将注意力集中在一个遥远的橙色点上，就会在其后方找到一个星系。 您探索银河系以查看恒星。 您观察到一颗恒星，以发现其行星和卫星。 你一直走下去，直到在某个地方找到你和我！
2.计划和实践使事情变得完美 (2. Planning and practice make things perfect)
Once you have identified the parts, select one logical piece to make a start. Be humble, and select the simplest of the pieces, to begin with.
识别零件后，选择一个逻辑零件开始。 谦虚，并选择最简单的作品。
The planning process can be challenging, especially if this is your first serverless development. There can be many technical and non-technical elements to look into and plan for.
计划过程可能具有挑战性，特别是如果这是您的第一个无服务器开发。 有很多技术和非技术元素可供研究和计划。
When you start fresh, don’t get distracted with most of the things in the above diagram. Identify the immediate needs, and the rest will follow suit as the solution evolves.
当您重新开始学习时，请不要对上图中的大多数事情分散注意力。 确定当前的需求，其余的将随着解决方案的发展而效仿。
Develop an architectural vision for the piece that you are starting with. Think of the serverless services that are fit for purpose to the best of your knowledge. Come up with a design that looks to provide a minimum viable product (MVP). You can always improve as you gain more experience.
为您开始的作品开发构架愿景。 考虑一下据您所知适合于目的的无服务器服务。 提出一种旨在提供最低可行产品(MVP)的设计。 当您获得更多经验时，您总是可以改进的。
If necessary, practice the design with a minimalist implementation, also known as, the Proof of Concept (PoC). Make sure the time you invest in doing the PoC is not wasted. Never start with a throw-away PoC mindset. Think of the PoC as your first iteration towards your design. With cloud and serverless, there is no reason why you should waste your effort.
如有必要，请以极简实施(也称为概念验证(PoC)) 实践设计 。 确保您在进行PoC上花费的时间没有浪费。 永远不要以抛弃式PoC心态开始。 将PoC视为您设计的第一个迭代。 有了云和无服务器，您就没有理由浪费您的精力了。
As you go through the design and the implementation of one piece, you slowly start to think of other related parts. Your thoughts expand, ideas develop and the mountainous task on hand sees a glimmer of hope!
当您完成一件作品的设计和实现时，您会慢慢开始思考其他相关部分。 您的想法不断扩大，想法不断发展，手头的艰巨任务充满希望！
3.在练习场进行排练可以使其更接近主舞台 (3. Rehearsing at the practice ground takes it closer to the main stage)
The ease with which a solution can be tested in a production-like environment has never been this convenient. So, make full use of the power of serverless.
在类生产环境中轻松测试解决方案从未如此便捷。 因此，充分利用无服务器的功能。
Create separate cloud accounts for your test and production. Whether you call it a test account or a production account, for the cloud provider, these are simply a logical separation of their same platform. It’s us who make that differentiation by configuring different access controls and account privileges to mark the separation.
为测试和生产创建单独的云帐户。 对于云提供商，无论您称其为测试帐户还是生产帐户，这些都是它们相同平台的逻辑分离。 是我们通过配置不同的访问控制和帐户特权来标记分隔来进行区分。
Two of the most common patterns are-
两种最常见的模式是-
1. One developer account to be shared by all the engineers. One QA account. One Acceptance or Pre-Production account and the Production account.
1.一个开发者帐户， 由所有工程师共享 。 一个质量检查帐户。 一个验收或生产前帐户和生产帐户。
2. One developer account per engineer. One QA account. One Acceptance or Pre-Production account and the Production account.
2. 每个工程师一个开发者帐户 。 一个质量检查帐户。 一个验收或生产前帐户和生产帐户。
Having an individual developer account has the benefit of hassle-free developer experience. At the same time, this requires more administrative overhead to set up the accounts, access permissions, and keep track of the monthly bills.
拥有单独的开发者帐户可带来无忧的开发者经验。 同时，这需要更多的管理开销来设置帐户，访问权限并跟踪月度账单。
Having a shared developer account can become a deployment nightmare with one engineer overwriting another’s deployment of the same service. But, there are ways to overcome this.
拥有一个共享的开发人员帐户可能会成为部署的噩梦，一名工程师会覆盖另一名工程师的同一服务的部署。 但是，有一些方法可以克服这一问题。
If a large team shares one account, then it may encounter the account level service and resource limits set by the cloud provider. Though most are soft-limits, you may encounter hard-limit situations as well.
如果一个大团队共享一个帐户，那么它可能会遇到云提供商设置的帐户级别服务和资源限制。 尽管大多数是软限制，但您也可能会遇到硬限制情况。
Where possible, keep the service configurations the same across all the environments. Configurations such as lambda timeout and memory, SQS polling interval, Firehose buffer size, and other services’ properties can be the same in production and non-production environments. However, there are situations where this is not always going to be the case. For example, due to legal obligations, the data retention policy can differ between production and non-production environments.
尽可能在所有环境中保持服务配置相同。 Lambda超时和内存，SQS轮询间隔，Firehose缓冲区大小以及其他服务的属性等配置在生产和非生产环境中可以相同。 但是，在某些情况下并非总是如此。 例如，由于法律义务，生产和非生产环境之间的数据保留策略可能会有所不同。
4.不同的人在不同的零件上工作 (4. Different sets of people work on different set-pieces)
A single purpose function does one thing and one thing well. When you work on small independent services, you channel your energy and focus on that. The same concept, when practiced across the team, increases the overall motivation and productivity. Among other things, the two important factors that help to achieve this are,
单一功能可以很好地完成一件事和一件事。 当您从事小型独立服务时，您会集中精力并专注于此。 在团队中实践相同的概念可以提高总体动力和生产力。 除其他外，有助于实现这一目标的两个重要因素是：
- The architectural design 建筑设计
- The development environment 开发环境
As mentioned in the section below, designing each piece as an independent service plays an important part. The event-driven and decoupled nature of the services allows the team to work on different pieces in parallel. Together, they contribute towards a shared goal.
如以下部分所述，将每个组件设计为独立服务至关重要。 服务的事件驱动和分离性质使团队可以并行处理不同的部分。 他们共同为共同的目标做出了贡献。
To aid service isolation and prevent dependencies between services forming, the development tools and the environment must be supportive. In the code repository, think of individual packages and dedicated commit, test and deployment pipelines for each service.
为了帮助服务隔离并防止服务形成之间的依赖性，开发工具和环境必须是支持性的。 在代码存储库中，考虑每个服务的各个软件包以及专用的提交，测试和部署管道。
5.所有部分共同构成整体 (5. All the pieces together make the whole)
No matter how we break down an application, all its parts must come together and function as one.
无论我们如何分解一个应用程序，它的所有部分都必须组合在一起并作为一个整体起作用。
In a movie, the scenes are edited together with dialogues, background score, and sound effects. In serverless, we have events, messages, and APIs, as the medium to knit all the set-pieces together. They are the nerves behind the serverless applications that bring life to the set-piece development.
在电影中，场景与对话，背景得分和声音效果一起被编辑。 在无服务器中，我们拥有事件，消息和API，作为将所有组件组合在一起的媒介。 它们是无服务器应用程序背后的神经，这些应用程序使机顶盒开发充满活力。
Above is an intentionally blurred architecture of an email notification application. A traditional text book style microservices application would have implemented this as one (macro)service to run in a container. In the next article, we will see how this monolith microservice thinking can be broken down and developed as several serverless set-piece services.
上面是电子邮件通知应用程序的故意模糊的体系结构。 传统的教科书式微服务应用程序会将其实现为一项在容器中运行的(宏)服务。 在下一篇文章中 ，我们将看到如何将这种整体式微服务思想分解并发展为几个无服务器的固定式服务 。
新思维方式的开始！ (The beginning of a new way of thinking!)
Visualize your serverless applications as a collection of set-pieces. Serverless gives us functional and granular level service features. By utilizing these unique characteristics, we can easily shift our thinking from a coarse-grained microservice to fine-grained serverless services.
将无服务器应用程序可视化为成套组件。 无服务器为我们提供了功能和粒度级别的服务功能。 通过利用这些独特的特性，我们可以轻松地将思想从粗粒度微服务转变为细粒度无服务器服务 。
When you start your serverless development, free your mind to go beyond the tradition to bring fresh ideas. New technology requires new thinking. If serverless gives you wings, then make full use of them and accelerate your cloud journey to enter new territories.
当您开始无服务器开发时，请解放思想，超越传统，带来新的想法。 新技术需要新思维。 如果无服务器为您提供支持，那么请充分利用它们，并加速您的云计算之旅，以进入新领域。
Go Build Serverless!
去构建无服务器！
服务器开发和服务器应用开发
扫一扫
1228
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
