Serg Hospodarets blog
I was delighted to be a speaker at the upcoming PlatformCon conference and share my experience on Platform Engineering.
I shared the experience from my journey of building great teams and with them delivering the Platforms to enable the business and customers.
The talk guides you on how to proceed with the Teams and organization topology, which tooling and approaches will help you, and how to build the culture and deliver.
No talk is good without the demo, so expect the live demos 🙂
The tech industry went from IT to DevOps, and now we are in the era of Platform Engineering teams. They are to enable the business, and create a company-specific platform to develop and deliver their products.
It requires an abstraction level on top of Cloud providers (AWS, Azure etc.) and tooling (K8S, Terraform..), including specific app type templates (Express, Spring Boot, Flask etc.) and CI/CD pipelines (GitLab, Github) + observability and security enablement, to move the cognitive load from the product delivery teams.
Preparing a business use-case, building a team, picking the right tooling, fostering the culture, solution and approaches are complex, but there is a common set of patterns and tools, so this talk is to describe both the reasons why Platform Engineering is a must, and to demo which tooling and approaches will help you to start.
Curated list of solutions, tools and resources for Platform Engineering
The complexity of Front-End applications grew past years extensively. That’s the reason big monoliths started being split to separate UI and modules working with different API. After years of using custom solutions and confusion around Micro Front-Ends, we are in the new era of the native support of Module Federation in Webpack 5, and tools, such as Storybook components system, SPA, and others switching to the common standard.
But this gives the tool to build apps which can work with specific microservices, and behind there are different topics- which use cases micro apps are useful for, what about coordination of shared modules interaction, their promotion and deployment of the newer versions, how they scale, how teams and work can be organized.
In this talk, the above areas will be discussed, and together with the live demos, you’ll learn about the current state of the art.
All the modern browsers support native JavaScript modules, and it’s a perfect time to start using them, which will change the way we are bundling the JavaScript using Webpack, Rollup, and other bundlers, and how the code is executed.
We will take a look how they work, what is the level of support in the browsers and Node.js, plus main findings and gotchas on the way of publishing and using them in production.
Looking into examples, we will understand the native modules features, performance details and lazy loading JS modules techniques.
...Today CSS Custom Properties are supported in all the major browsers.
Now it’s time to do the next step- to have an ability to register new Custom Properties from JavaScript and setup the browser how to work with them (e.g. real CSS polyfills). They should work with the same performance as the native CSS properties, being animatable and aligned with CSSOM.
Custom Properties can be used as a bridge between CSS and JavaScript. Houdini Task force introduces specs and JavaScript Worklets to expose the interaction with previously fully internal browser rendering mechanisms (during Paint, Layout, Composite stages).
All this brings Front-End development to the next level, parts of which are already available for the developers.
...