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.
CI/CD / Cloud Native Ecosystem

Lightbend Survey: Cloud Native Is a Process, Not a Place

For IT leaders, cloud native isn’t so much a place or a thing — it’s something they do. It's what cloud computing enables customers to do differently.
Oct 27th, 2020 9:06am by
Featued image for: Lightbend Survey: Cloud Native Is a Process, Not a Place

Lightbend sponsored this post.

Klint Finley
Klint Finley is a professional writer and analyst who specializes in enterprise computing and developer technology. He served as a staff writer at Wired for nearly 8 years where he reported on such topics as artificial intelligence, cloud computing, and data science. His work has also appeared in ReadWriteWeb, TechCrunch, and BoingBoing. Klint is based in Portland, Oregon.

As cloud computing matures, it’s becoming more and more clear that the important thing isn’t where your applications run — or even what specific technologies underpin cloud services. The important thing is what cloud computing enables customers to do differently.

Cloud computing and related technologies are going mainstream at a rapid rate. According to a survey of 1,000 developers and IT decision-makers conducted by cloud native software company Lightbend, 38.5% of organizations say they are moving aggressively to adopt a cloud native strategy and another 33.8% are in the early stages of adopting a cloud native strategy. Meanwhile, 59.2% say they’re already running most new applications in containers and/or on Kubernetes clusters.

But the executives interviewed in conjunction with the survey think about cloud native less in terms of where their applications run, but rather in how those applications are built. For these IT leaders, cloud native isn’t so much a place or a thing — it’s something they do.

Some executives also expect to save money or improve availability by shifting workloads to the public cloud. But nearly everyone surveyed said that their core goal in adopting cloud native technologies is to get applications and features to market more quickly. “The benefit of going cloud native is the speed of building software and the ability to collaborate while you’re building it,” says the VP of IT at a manufacturing company.

Part of that means taking full advantage of the unique technologies that cloud providers offer (such as machine learning APIs) that save customers from the need to build those features themselves. “If we want to use natural language processing or AI we don’t want to build that if we can just rent the capabilities from Amazon or Azure,” says the CISO of a large financial software company. “We can get to market faster when we leverage those cloud services.”

But perhaps more to the point, executives say that going cloud native is about adopting processes that allow developers to adopt continuous integration (CI) and continuous delivery (CD).

For the uninitiated: CI is the practice of having programmers commit their work to central repositories frequently so that the repository always has the latest changes. CD is the practice of being ready to deploy those changes at a moment’s notice.

Instead of making lots of big changes to a piece of software all at once, as is done with traditional “waterfall” style code releases, developers make incremental changes to software. The idea is that this makes the process faster overall, because the small changes can be validated more quickly and efficiently.

“When you make a very simple change, you should be able to click a button and those features should be running on the cloud within about thirty minutes,” says the CTO of a major e-commerce site. “I don’t want it to take hours or days.”

It’s a cloud native approach to development, although it’s not something that would work for software mass-produced on physical media.

There are many different software packages designed to handle CI/CD workflows, but CI/CD is about more than just picking some software off-the-shelf. It requires developers to change their processes and practices. “We shifted to agile-only project management as part of our cloud migration,” says another CISO of a financial services company.

CI/CD also encourages a different, more cloud native approach to architecture. “Breaking things down into microservices makes it easier to do continuous delivery/deployment,” says the CTO of a technology company. That’s because when functionality is isolated into different microservices, individual developers or teams can focus on their own code and worry less about breaking changes to another part of an application. It can also make it easier to incorporate cloud native functionality, like APIs or serverless.

Whether to use a public cloud service or a private cloud service, whether to run workloads in containers or virtual machines, and whether to go all-in on function-as-a-service — these are all important decisions facing today’s enterprises. But which cloud technologies you use are secondary to the question of how to build them.

Download your copy of Cloud Native Adoption Trends 2020-2021 to explore the ongoing tension between developers and IT leaders around what the highest priorities are for cloud native migrations.

Feature image via Pixabay.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.