diff --git a/blog/2023-07-18-wing-cloud-launch.md b/blog/2023-07-18-wing-cloud-launch.md index df4c2b789..380e62a15 100644 --- a/blog/2023-07-18-wing-cloud-launch.md +++ b/blog/2023-07-18-wing-cloud-launch.md @@ -28,7 +28,7 @@ environments, test their systems or deploy them across multiple public providers I don't think I've ever talked to a platform team that feels like they got it right, or to a DevOps engineer that didn't feel they are a bottleneck. I hear frustration and apologies "I know this is not ideal, but we've got to give developers a way to develop". When I talk to enterprises, many of -them are in “analysis paralysis”. Which cloud provider do we sell our souls to? Are we a serverless +them are in "analysis paralysis." Which cloud provider do we sell our souls to? Are we a serverless shop or a Kubernetes shop? Do we now need to teach all developers how to configure a VPC?. When I talk to Kubernetes shops, I hear denial. It usually starts with "everything is in our @@ -181,7 +181,6 @@ mechanism we have for portability across clouds is used to implement a local clo for each resource in the WCL. This means that my entire Wing application can run in a local machine and be functionally tested. - ### Tests as first-class citizens I love tests. I believe that tests are the most important asset a software team builds. My code can @@ -201,7 +200,6 @@ and with other pieces of my system. To that end, the Wing language, the SDK and the Wing Console all work together to offer first-class support for [cloud testing](https://www.winglang.io/docs/concepts/tests). - Tests in Wing are multi-cloud by default and can all run in parallel because they use cloud functions as their compute resource. Every test you write can be executed locally in the cloud simulator and can also be deployed and executed across all supported cloud providers. @@ -226,8 +224,6 @@ will also watch for any file changes, recompile and reload as needed. Batteries **We are planning to offer Wing Console for production**. This means that users will be able to connect to a deployed system and operate their production systems through Wing Console. - - We believe this addresses a major pain when operating cloud applications. Today, we manage applications "from the bottom", i.e. from the resources up. I go to my cloud provider's administration console and what I see is a bunch of low-level resources - queues or buckets or @@ -249,11 +245,11 @@ The solution, today, is dashboards. I have to manually craft these views to repr model of my system. I take the red and green and blue pieces and arrange them together under the title "Gate", and now if there's an error, I can tell where it belongs. -It goes back to the *space and time* analogy. The operational experience of Wing Console is based on -Wing's *spacial view* of the system. Every resource or event can be *traced back* to the logical -unit it belongs to, based on your source code. This is basically the purpose of stack traces in -traditional languages - an exception is thrown and the stack trace helps me trace back from -low-level to high-level so I can diagnose the problem. +The operational experience of Wing Console is based on Wing's preflight structure of the system. +Every resource or event can be *traced back* to the logical unit it belongs to, based on your source +code. This is basically the purpose of stack traces in traditional languages - an exception is +thrown and the stack trace helps me trace back from low-level to high-level so I can diagnose the +problem. ### Fully customizable below the abstraction