Will JavaScript type annotations kill TypeScript?
The creators of Svelte and Turbo 8 both dropped TS recently saying that "it's not worth it".
Yes: If JavaScript gets type annotations then there's no reason for TypeScript to exist.
No: TypeScript remains the best language for structuring large enterprise applications.
TBD: The existing user base and its corpensource owner means that TypeScript isn’t likely to reach EOL without a putting up a fight.
I hope they both die. I mean, if you really need strong types in the browser then you could leverage WASM and use a real programming language.
I don’t know and I don’t care.
Frontend Development / Serverless / Software Development

Forrester Identifies Best Practices for Serverless Development

IT research firm Forrester says there are four best practices for serverless development, including designing for ephemeral functions.
Sep 9th, 2022 6:00am by
Featued image for: Forrester Identifies Best Practices for Serverless Development
Feature image via Shutterstock.

Serverless development is rapidly maturing, according to Forrester analyst Devin Dickerson, who researches trends and best practices about the approach.

Dickerson is the lead author on a new report on best practices in serverless development and delivery. The New Stack asked Dickerson to explain what developers need to know about a deployment in serverless environments.

In many ways, the growth of serverless can be traced to the DevOps movement, which pushed some operations issues back to development, Dickerson said.

“As a byproduct of that, developers all of a sudden had to worry about a lot more operations concerns than they had before,” he said. ”Serverless is beneficial, because it removes those operations concerns […] from developers.”

Of course, serverless doesn’t mean literally serverless. It’s just that the server is managed and virtual. But for developers, serverless eliminates many of the operational hassles — which may explain its popularity. In Forrester’s 2022 developer survey, 33% of 2,452 developers said they are currently using serverless architecture, with an additional 30% reporting that they want to use it.

Design Services as Ephemeral Instances

One of the biggest considerations with serverless is that applications are deployed in functions that only run when invoked or triggered by an event.

With traditional microservices-based applications, and even monolithic applications, the developer has a full view of what’s going on in production, Dickerson said. That’s not the case with serverless applications, where there are parts that simply aren’t running sometimes.

“When you do design a serverless application, you have to consider that it’s not going to be running all the time,” Dickerson said. “Once they’re not running anymore, they will go away.”

Designing for that means making microservices discrete, single-responsibility functions. It also means designing functions to execute and then go away, the report notes.

“When serverless developers build for short-running, independent workloads, they gain the benefits of autonomous horizontal scaling that can complete in a fraction of the time and at a fraction of the cost,” the report stated. Function payloads should be small and reduce dependencies to deliver optimal performance, it added.

Serverless architecture works well if there are independent workloads with sporadic demand, but it’s not the best approach to use if you have “serialized units of work that are difficult to process in parallel,” the report stated.

Pair Function-as-a-Service with Event-Driven Microservices

While function-as-a-service platforms — such as AWS Lambda, Azure Functions and Google Cloud Functions — are key for development, they’re only a starting point, Forrester contended. Developers can also pair functions with event-driven microservices as a best practice.

“There are serverless applications that are fully serverless, so you might have a situation where you’ve developed a capability where the use case is appropriate to do the whole thing serverlessly,” said Dickerson. “But more often, you will see serverless functions alongside microservices and overall cloud native application.”

Building microservices as discrete functions that consume and emit events can allow developers to take “full advantage of the ephemeral scale-out benefits of functional programming,” the report stated. It recommended four steps in implementing event-driven microservices as functions:

  1. Design a taxonomy of events and domains. GitHub Actions can help implement microservices as functions, it added.
  2. Use event queues to drive autoscaling performance. “Developers can configure serverless platforms to monitor the depth of event queues and respond appropriately when performance starts to degrade,” the report noted, comparing it to “that wonderful moment when you’re standing in a long line and three clerks suddenly open windows to serve customers.”
  3. Design to allow multiple microservices to respond to the same event.
  4. Assume the multiple versions of a service may respond to the same event. “Developers can use canaries and blue/green deployments to evaluate new service versions in production.” Serverless frameworks and tools such as the Canary Plugin from Serverless Framework enable this functionality, it adds.

Design Functions with Autoscaling in Mind

To design functions with autoscaling in mind, break activities into small independent tasks that can deploy individually. Developers should also minimize the mount of time functions spend waiting to deploy, since execution time is the biggest cost driver in a serverless environment, the report cautioned.

Also, Forrester noted that the traditional large relationship database management system won’t work well in a serverless environment, because of the tight coupling. “Instead, serverless developers decouple state from their business logic using faster NoSQL approaches and state machine workflows like step functions,” stated the report.

Embrace Change with Fault-Tolerant Services

Finally, plan for failure up front by discovering critical failure points, mitigating integrations risks and other predictable fault lines, and test the application’s failure strategy with chaos engineering and testing, advised Dickerson.

An application running with multiple serverless, functions, and receiving events at different times requires a more robust approach to testing, in which the developer tries to simulate things that could go wrong in production. Netflix has used this chaos testing approach to great effect, he added.

“Chaos engineering is essentially when you try to break your own system […] with the purpose of creating more resilient applications,” Dickerson said. “This is not unique to serverless, but it is a technique that should be used with serverless.”

Group Created with Sketch.
TNS owner Insight Partners is an investor in: The New Stack.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.