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.

Eliminate Friction in App Delivery to Kubernetes

Apr 10th, 2019 3:00am by
Featued image for: Eliminate Friction in App Delivery to Kubernetes

Anoop Balakuntalam
Anoop Balakuntalam is a curious technologist based out of Hyderabad, India. In the last 18 years, he has founded ventures in the areas of web development & server management, built a cloud practice serving Fortune 500 clients and has been instrumental in developing various cloud-based applications and SaaS products. Combining his deep interest in DevOps & software architecture with his passion for building inspired teams, he is currently busy building a frictionless app delivery platform for Kubernetes at HyScale.

The last two decades have seen a sea change in the way software is written and delivered. Waterfall to iterative to agile, native to hybrid to responsive interfaces, monoliths to microservices, installed to pay-as-you-go SaaS, data centers to private and hybrid clouds, and virtual machines to containers.  As the market constantly evolves, enterprises are facing a ton of choices with increasing complexity.

When microservices came along to break up huge monoliths into manageable parts, it meant teams still had to manage those individual parts, each with their own lifecycle. Containers (you know where that metaphor came from) solved some of that complexity by packaging each part and all dependent information into self-contained, repeatable units. This is where our story begins.

With the advent of containers as an economical portable solution, software began to be packaged along with its stack dependencies as an immutable “container image.” Once you have an image, you can launch any number of identical containers. This guarantees outcomes that are predictable and consistent overcoming the familiar software challenge — the “works for me” syndrome.

The Rising Need for Automation

Microservices and containers are typically hand in glove. With container images being “immutable,” any change to the service code or its dependencies entails building a new image. This means refreshing images built from the new code and replacing the relevant containers. In an enterprise with hundreds of apps, each containing multiple services, this means hundreds of new images & container replacements in a cycle of change. This demands a massive collaborative effort among developers and IT/DevOps. The situation is in desperate need for automation and process standardization.

Automation would help enterprises auto-containerize hundreds of services without having to write manual scripts, custom code or lots of configuration files. It would also lead to process standardization in order to prevent a proliferation of custom methodologies across teams and to reduce dependence on specific people for know-how.

With Kubernetes (k8s) emerging as the de facto container orchestration platform for hosting containers, a good process and automation would also facilitate a clean hand-off interface between those managing the k8s cluster/infrastructure and the app teams who are doing app delivery to the cluster. Only then can app teams develop, test & deliver apps with the least amount of friction enabling rapid updates of enterprise applications while also helping the enterprise realize the benefits of containers and k8s.

The Cause of Friction in Enterprises

Container DevOps is becoming all about ensuring Frictionless delivery. Here are a few overarching goals for this to become a reality. Foremost is speed. If a dev team’s need for a new test environment involves putting a ticket and waiting a day or two, that’s friction. The lack of a well-defined hand-off interface between application & IT teams, for information to be shared and collated in an error-free way, also leads to friction. If making changes to a couple of services and deploying them to staging or production environment involves manual intervention and takes a couple of hours or a day, making it an event, then that’s friction too.

Eliminating Friction for a Seamless Delivery

An enterprise’s best bet at eliminating friction is to adopt an automated self-service experience that enables app development teams to input service-related information and trigger delivery on demand. Such a delivery platform must combine pieces of information from the various owners in a reliable way. At the same time, black box automation may not win the confidence of app development teams who want to track changes made to service configurations and dependencies, visualize & identify configuration changes between different environments of an app. Most teams are already using CI scripting mechanisms and tools. It would be ideal if the automation leverages as many existing investments around CI as possible with minimal disruption to the roles and workflows in the organization.

Enterprises today would, therefore, be well served by moving away from a script-based & people dependent approach to delivery, and towards a platform-based approach. Such a delivery automation platform would provide a frictionless and continuous delivery experience to Kubernetes allowing them to tap into all the intended benefits of containers: improved cost economics, speed, and reliability of deployments, and app portability across multiple clouds.

Feature image by markito from Pixabay.

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