开源日报 - Page 149 of 262

开源日报第448期：《辅助功能 awesome-AutoHotkey》

6 6 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《辅助功能 awesome-AutoHotkey》
今日推荐英文原文：《How I Taught My Mom to Code》

今日推荐开源项目：《辅助功能 awesome-AutoHotkey》传送门：GitHub链接
推荐理由：上个月我们刚刚介绍过 AutoHotkey 这个可以帮助你更方便工作的脚本语言，这次要介绍的是有关它实用的工具，库以及一些脚本的完成品。一些诸如自动补全和窗口管理这样的脚本能让你省下不少功夫，而如果你自己去实现它会花掉不少时间——别忘了你使用这玩意是拿来节省时间的，怎么省事怎么来才是好选择。
今日推荐英文原文：《How I Taught My Mom to Code》作者：Lee Stetson
原文链接：https://medium.com/better-humans/how-i-taught-my-mom-to-code-9365db560140
推荐理由：且看作者如何教妈妈写代码
How I Taught My Mom to Code
So, you want to learn to code. I’m going to share 7 tips today that will help you succeed in learning to code no matter what your background, skills, or confidence. They helped my favorite, most inspiring student to learn how to code. She went from knowing zilch–zero!– about computers to building a website for her business.

That student is my mom.

My mom, LoriSue, felt unhappy and trapped in a job she hated. She needed to learn more about computers if she wanted to switch career paths this late in life (she’s 56). So she went back to college and enrolled in an introduction to computers course.

Or so she thought.

What my mom really enrolled in was a web development course, which was a bit too advanced for her. But since the course sounded fun, and was in-line with her ultimate goal, she decided to stick with the course.

People judged her because of her background. Almost nobody believed she would be able to complete the course and even if she did, they didn’t expect her to use any of the skills she learned. Her confidence dipped in those first few weeks as she struggled with the coursework and faced the negative feedback.

That’s when my mom asked for my help. She was overwhelmed but driven to succeed. So we put together a plan based on 7 strategies I knew worked from my experience teaching my clients, friends, and colleagues how to learn to code.
0. Believe in yourself
It’s easy to feel like you don’t know what you are doing when you start writing code. It’s easy to give up–my mom sometimes felt that she should. But it’s important to admit when you’re feeling this way so that you can take a step back, focus on (and appreciate!) what you do know, and also positively frame the next steps you need to take to achieve your goals. Little by little, you can understand the gaps in your knowledge and overcome them. The more confidence you have in your work, the better you’ll be at it, too.

Tip: Have confidence in yourself. If you aren’t feeling confident, pause and reflect on everything you have learned so far in coding and how far you’ve come from day one. And if you need it, find someone–a friend, family member, or coach–who can reaffirm how much you’ve accomplished.

With my brothers, literally supporting my mother.
1. Write code every day
I made my mom commit to coding a little bit every day. Learning to program is like learning any other language: practice builds muscle memory and keeps the language fresh in your mind. You won’t go far if you just code on weekends or during class office hours. My mom practiced every day and I checked up on her to make sure that she did. I also called her after her lectures and had her explain to me what she learned, which helped the concepts sink even further into her memory and easily surfaced problem areas that she might have missed.

Tip: Practice every day, even if just for 10 minutes. Go over what you learned the day before to make sure you are building on the concepts and testing what you know.
2. Learn by copying others
At first, I asked my mom to type out the code that she saw in lectures, even if she didn’t understand what it did. And for the most part, she didn’t understand it. Not at first. Over time though, she started to see patterns and realize how the code fit together. Soon she was writing new code every day and even fixing bugs.

Tip: Pay attention to the examples in your introductory courses. If you can’t figure out how to write something, search on Stack Overflow.
3. Take advantage of free resources
Don’t try to memorize everything–build a solid list of resources you can keep in front of you. Programmers hate memorizing things that can be easily looked up at the appropriate time. That’s partly why you find so many great resources on the web such as Stack Overflow, free tutorials, and language guides. Every now and then my mother would find herself overwhelmed by how much material there was. She kept worrying that she would have to memorize everything. You’ll memorize common functions and basic syntax for sure, but most of the time, you’ll be looking in documentation to remember how to use the pieces of code. Your job is to learn how to put it together, not how to memorize code.

Tip: Find helpful guides and bookmark them, save them as a file on your desktop, or print them out to keep next to your computer. I found a 1-sheet printable list of common functions in JavaScript that I sent my mother–she was so relieved and uses it to this day. You can find top guides through google searches or in forums.
4. Don’t be intimidated or think a question is too stupid to ask
When she started off, my mom didn’t understand the technical concepts of how a computer worked. She was intimidated to see other students goofing off when the teacher explained basic concepts she didn’t understand. They seemed to know something she didn’t. She was embarrassed to be so far behind! I worked with her to focus solely on where she was and how to keep improving. Over the course of the semester, I had her look at the code from class to find general patterns. I also encouraged her to ask questions and made sure to explain the technical concepts in layman’s terms, which she found incredibly helpful. Eventually, she was able to talk technically, and speak the language, all without putting a particular focus on the language specifics.

Tip: We all start somewhere. Focus on where you are on the next step you need to take to improve. A hard work ethic will pay off. Also, most programmers I know love to answer questions (when they know the answer) and won’t judge you for asking too simple of a question. Ask away!
5. Learn how to ask the right questions
You’re going to get stuck when you’re writing code. I still do and I’ve been programming for 15 years! Sometimes it’s just a semicolon that breaks your code. As a beginner, you’ll spend hours trying to fix it. Frustration could lead you to focus on minor details instead the solution. When my mom got stuck, I’d encourage her to step back, think about what her code was supposed to do, and then compare that to what the buggy code was doing. By asking the right questions, she’d quickly find the errors and correct them with only the help of my guiding questions.

Tip: Embrace the process of learning how to code and it’s unloved cousin, learning how to debug code by asking the correct questions when your code doesn’t work. Have patience. And find a friend, mentor, online community, or coach who can help you learn how to ask the right questions when you get stuck.
6. Get a coach
When my mom realized she was in over her head, she attempted to make use of the professor’s office hours to gain the knowledge she was missing. But the professor had to keep pace with his curriculum, and he didn’t really know how to help someone at her technical level get up to speed. He provided encouraging words, but couldn’t offer any guidance. That’s when she realized she needed someone who understood her challenges, as well as what steps were necessary to train her mind to think like a programmer.

Tip: Get a coach! We don’t just know these tricks, but we also know how and when to apply them for leverage. I’ve heard the argument that learning to code on your own is actually impossible. This might not be true, but finding that person who will invest in you, and has the coach’s toolkit will virtually guarantee real forward progress in learning to code.

Guess what? At the end of the semester, other students were coming to my mom for help on their final projects. She completed the class. In fact, she earned the highest grade out of all the students (she schooled them!). I was so proud of my mom. And so lucky to witness her growth as a programmer over the course of the semester. She’s already put what she learned into practice to build a website for her new side business. My mom’s story could easily be your story.

Whether you’re brand new to coding or looking to master a particular language; whether you’re young or old; no matter if you’re taking classes or learning on your own; if you’re just starting to explore coding or ready to apply for jobs, you can learn to code.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第447期：《桌面版 desktop》

5 6 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《桌面版 desktop》
今日推荐英文原文：《Why I Switched to Open Source》

今日推荐开源项目：《桌面版 desktop》传送门：GitHub链接
推荐理由：除了能在 GitHub 上看到它的微信小程序版，还能看到它的桌面版，这个项目正是一个基于 Electron 的 GitHub 桌面应用。对于熟练工来说使用 app 和使用命令行界面可能没什么区别，但是对于初学者来说图形界面的确比起命令行界面来说更友好也更容易上手，使用它来先学习 Git 的关键功能是个不错的选择。
今日推荐英文原文：《Why I Switched to Open Source》作者：Bob Roebling
原文链接：https://medium.com/@broebling/why-i-switched-to-open-source-9cce60b11cc4
推荐理由：开源可能没那么来钱，但是它能更好的帮助别人
Why I Switched to Open Source

My journey from a proprietary advocate to an open source idealist.
When I was in college, I was a die-hard for proprietary software. Microsoft and Apple were the leaders of this showdown while Linux and Google were my mortal enemies.

I had a strong dislike for anything open source because I cared deeply about security and privacy. In my mind, evil-doers would look at open source and either make changes to the code to make it vulnerable or find vulnerabilities in the repository and exploit them to gain access to my computer.

I stuck with the pre-built apps and knew that if I paid for commercial proprietary software, I would be safe from all those evil-doers.

Reports of all of the malware on Android phones and the opposing lack of malware on iPhones only justified my beliefs so much that I wrote an argumentative paper in Composition II on why proprietary software was better than open source.

My teacher was surprised. “Normally I have to listen to students defending open source,” she said, adding more fuel to the fire that drove me to cherish proprietary software. I was so adamant that I even shut down people who argued against me at the end of the essay.

After I graduated from college and a few jobs later, I started getting into software development. My first job as a developer was as a COBOL developer; it was hard at first. The only way of getting any knowledge about how to write COBOL programs was from a handful of websites and senior developers in my department. I was working with proprietary software.

I left the company a few years later to work at another company that I felt I could move away from structured programming and get into a newer object-oriented language. I had to start somewhere, and they needed COBOL developers. That was my way in, and after a year, I moved to a different department where I started writing Python and deploying code to enterprise Linux servers.

Photo by Brad Barmore on Unsplash

As I settled in, I started to find a plethora of resources that enabled me to do my job. I found community groups in forums, Slack, and even in my city that acted as support groups for learning programming and helping you work through issues in your code.

It was at this point where I started seeing how open source made developing new tools more efficient. As I ingrained myself more rooted in the community, I noticed something particularly compelling. People were interested in helping others. People were making tools for free to help others accomplish tasks more efficiently. Those people weren’t looking to be paid for their works, but the ones who made things that were adopted by many people were given donations to continue their work.

When I was defending proprietary software, it was easy because I was looking at the monetary value of what was created. Open source had very little to do with making money, and it was more about creating a culture that could be adopted where people cared more about their reputation to help others than they did about money.

It wasn’t just one person that worked on open source software either. As projects became more widely used, more people would jump on the project to assist in bug fixes, vulnerabilities, and adding new features. This means 0-day vulnerabilities are fixed within days, sometimes they are fixed before they are even announced to the public.

Proprietary operating systems have release cycles when it comes to updates. Windows is patched once a month, while macOS is patched about once a quarter. These patches include minor updates and security patches. Enterprise Linux is usually patched once a month, but non-Enterprise Linux editions are patched as soon as an update is available.

Proprietary software is typically patched like operating systems; however, open source software is patched as needed. This leads to open source software being more secure than proprietary software. Just because the public doesn’t know about it doesn’t mean everyone doesn’t know about it.

With that said, you still have to be careful about which software you use. While I do favor open source software, I primarily use Apple products because Apple has been the clearest on their security and privacy practices. Yes, I know about the iCloud hacks, yes I know about Apple charging too much for their devices (I’ll protest with you). But I don’t care for how much data Microsoft sends back about what I do on my computer, nor do I like how much data Google sends back about what people do on their Google accounts.

With open source products, you can review how much data they send back by looking at the code (it’s not hard to read). Google accounts are proprietary, so is the Windows operating system. If they weren’t, then you’d be able to pull up the metrics they return. I also don’t like some of their practices in the past, most recently, Google decided to scan through my mail and list all purchases made with a credit card not attached to my account and list them under my wallet. That seems way to invasive. There is no real description of what happens when I turn that feature off. Did I turn it off, or did I hide from myself?

I’m happy to run Linux. While I do not have the time to help contribute to open source projects, perhaps someday soon, I will be able to assist in making the software we use better. The culture of open source is the main reason I decided to leave, but deceptive practices done by proprietary companies has kept me from turning back.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第446期：《各种花样 css3-》

4 6 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《各种花样 css3-》
今日推荐英文原文：《An introduction to JSON》

今日推荐开源项目：《各种花样 css3-》传送门：GitHub链接
推荐理由：作者用 CSS 做出的看起来很有美感的效果合集，包括纯 CSS 实现的旋转着的立方体和加载图标等等。实际上在很多地方都可以看到诸如加载图标这样常见的效果，但是如果实际自己做一次而不是直接使用成品的话会有很多不同的发现和收获，对于吸收自己现有的知识也相当有帮助，而这些收获将在动手创造自己想法中特有的成果时都能够派上用场，可谓是一举多得之策。
今日推荐英文原文：《An introduction to JSON》作者：Raivat Shah
原文链接：https://towardsdatascience.com/an-introduction-to-json-c9acb464f43e
推荐理由：对于 JSON（JavaScript Object Notation），一种简单而常用的数据表示法的介绍
An introduction to JSON

A complete beginner’s guide

If you are into Data Science or Software Engineering or any related field, you may have come across the term “JSON”, and if you’re a newbie, you might be confused. In this post, I will try to introduce JSON without assuming any prior knowledge and explain the concept of JSON with simple examples. Let’s get started.
What is JSON?

JSON stands for JavaScript Object Notation. Don’t get carried away by the jargon, it’s actually straightforward to understand and use. As the word “notation” might hint, JSON is simply a way of representing data independent of a platform — this just means that it is something like a PDF (which is the same across different platforms like mobile, desktop and web) for data. The JSON format was specified by Douglas Crockford, and the filename extension is, as you can guess, .json.

Thus, the PDF for data travels across platforms and maintains consistency in representation and storage. It is widely used today and therefore, crucial in the fields of Data Science and Software Engineering.
Why JSON?

JSON sounds cool, but what is the motivation or purpose behind it?

As highlighted above, JSON being independent of a platform is one of the major choices of format for transfer of data between computers that exchange tons of data each day.

An alternative to JSON is XML (extensible markup language), but JSON is better in many ways. While both are human-readable and machine-readable, JSON is much easier to read and is also faster for computers to process. Furthermore, JSON is processed (or parsed) with a JavaScript parser (which is built-into most web-browsers) while XML requires a separate XML parser. This is where the “JavaScirpt” comes into play in “JSON.” The practical implication of this is that

You can read more about the differences here and here.
How to JSON?

After you’ve understood what JSON is and the rationale behind it, you can now jump into writing some JSON code. JSON syntax is very similar to JavaScript so it would be familiar if you have prior experience with JavaScript.

Let us work through an example to understand writing JSON. Let’s say that you are the leader of your neighbourhood and maintain a database for all the people in it. Consider a scenario when Mr Jodhn Appleseed moves into your neighbourhood. You may want to store information like his first name, last name, date of birth, marital status, etc. Let’s use JSON for this!

When you’re writing JSON, you’re essentially a match-maker! Yes, really! But instead of people, you match data. In JSON, data is stored as key-value pairs — every data item has a key through which you can modify, add or delete the data item. JSON files are enclosed by {} curly braces which contain these key-value pairs.

Let’s start by adding the first name and last names:
```
{
    "first name":"John",
    "last name":"Appleseed"
}
```
As you can notice, the values in the left column are the keys (“first name”, “last name”) and the values in the right column are the respective values (“John”, “Appleseed”). A colon separates them. The values encompassed with double quotes are of type String — which essentially means that they are meant to be text and not refer to something else (e.g. a number, variable in another part of the file, etc.).

Note that in JSON, all keys must be strings —so must be enclosed with the double quotes. Also, there’s a comma after each key-value pair except for the last one, indicating that a new item is being recorded.

Now, let’s add his age:
```
{
    "first name":"John",
    "last name":"Appleseed",
    "age":30
}
```
Note that there are no double quotes around the number 30. Intuitively, the data type of such data is number, and hence you can perform mathematical operations on them (when you retrieve the information). In JSON, this data type (number) can take on any numerical value — decimal or integer or any other type. Notice also how I added a comma after “Appleseed” as I added another item below it.

Let’s do something fun now. Let’s try to add his house, which would have its address, owner information, and city. But how do we add these things into the JSON file for John? Things like owner info are attributes of the house and not John, so it doesn’t make sense to add this info directly into the JSON file for John. Worry not, JSON has an interesting data-type to handle this!

In JSON, a value can also be an Object (something that is a key-value pair too). This object is just like another JSON file — enclosed with curly braces and containing key-value pairs, except that it is within our original JSON file instead of having a file of its own.
```
{
    "first name" : "John",
    "last name" : "Appleseed",
    "age" : 30, 
    "house" : { 
            "address":{
                "house no":22,
                "street":"College Ave East",
                "city":"Singapore",
            },
            "owner":"John Appleseed"
            "market price($)":5000.00
    }
}
```
As you may notice, the house is an Object, which contains the keys address, owner and market price. The data in address is also an Object, containing the keys house no, street and city. Thus, it is possible to nest objects within objects, and this allows for a more clear representation of data, as shown above.

Now, let’s add info about his friends. We might do this by adding “friend1” and name, “friend2” and name, and so on but this would quickly become boring. JSON provides a data type for storing such info effectively, and it is called an array. It is an ordered collection of items — which can be of any data type.

Let’s say he has three friends: Charles, Mark and Darren. Our JSON file would now look something like this:
```
{
    "first name":"John",
    "last name":"Appleseed",
    "age":30, 
    "house" : { 
            "address":{
                "house no":22,
                "street":"College Ave East",
                "city":"Singapore",
            },
            "owner":"John Appleseed"
            "market price($)":5000.00
    },
    "friends":[
        "Charles",
        "Mark",
        "Darren"
     ]
}
```
Notice that the array is enclosed with square braces and we wrote each item in a newline followed by a comma except for the last one. The new line is not necessary, but it helps the readability of the code for humans.

Lastly, let’s add his marital status. We could do something like “married”:”yes” but JSON provides a special data type for all dichotomous choices: a boolean. It can only take on two values: true or false. Intuitively, it can’t be both at the same time. Assume that John is a bachelor. Let’s add this final piece of information to our file! Our file now looks like this:
```
{  
   "first name":"John",
   "last name":"Appleseed",
   "age":30,
   "house":{  
      "address":{  
         "house no":"D12",
         "street":"College Ave East",
         "city":"Singapore"
      },
      "owner":"John Appleseed",
      "market price ($)":50000.00
   },
   "friends":[  
      "Charles",
      "Mark",
      "Darren"
   ],
   "married":false
}
```
Final JSON File for John Appleseed

And, you’ve familiarised yourself with JSON. In this article, we understood what JSON is, why it is useful and finally, how to do (some) JSON. In doing so, we learnt about the JSON data types (String, Number, Array, Object and Boolean).

The file above is a GitHub gist, and you can follow this link to download the file and play around with it, add some more info or make JSON files for new people. I hope this article helped you get introduced to JSON. Let me know how your journey is by responding to this story.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第445期：《大叔流 ojichat》

3 6 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《大叔流 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.
1. The amount of memory allocated and
2. 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 –
1. Reduced Cost
2. No Server Maintenance and Configurations
The main disadvantage of Serverless are
1. Cold Start.
2. 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 serverless
Coca 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.
1. Cold Start.
2. Reliance on 3rd party Vendors
Sure, the development environment has changed and that can take some time for a traditional seasoned developer to get used to — or not.

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://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/