Challenges of RDBMS-driven workflows

The growth in our business has introduced specific complexities that exacerbates the pain points of traditional RDBMS-managed workflows:

• Rapid Product Development: In dynamic insurance markets, rules and regulations change frequently, and new product offerings are crucial for our competitive advantage. The tight coupling of business logic to stored procedures significantly slows down the speed at which we can introduce and iterate on new products or pricing models.

• Catastrophic Event Scalability: Following a hurricane or other major weather event, claims volume can spike exponentially. Our DB-driven, monolithic systems become bottlenecks, leading to delays in processing critical claims and impacting our policyholder satisfaction during their greatest time of need.

• Audit and Compliance: Tracing the exact sequence of events for regulatory compliance or internal audits in a DB-driven workflow often means piecing together scattered data points.

• Retry Logic for External Integrations: We rely heavily on external services like payment processing, geolocations and more. Implementing robust retry mechanisms with back-off for these critical external calls within a DB-driven system is incredibly challenging and a common source of subtle, hard-to-diagnose failures.

• Limited Real-time Operational Visibility: Gaining real-time insights into the progress of a complex commission payment system or a high-volume policy registration is challenging. Identifying bottlenecks or policy application fallouts often relies on batch reporting or deep database queries, hindering our proactive intervention.

Enter Temporal: durable execution

Temporal is an open-source, distributed system that enables us to write durable, fault-tolerant, and scalable workflows as code. Instead of relying on a database for state management and orchestration, Temporal provides a dedicated platform that ensures our workflow executions are:

• Durable: Workflow state is automatically persisted, so even if our services crashes, the workflow execution will resume exactly where it left off. No lost data, no manual recovery of in-flight policies is needed.

• Fault-Tolerant: Temporal handles retries, timeouts, and error handling automatically for external calls (e.g., to third-party data providers, payment processors, or external rating engines). We define the business logic, and Temporal ensures it executes reliably, even in the face of transient network issues or external system outages.

• Scalable: Temporal is designed for high-throughput, long-running workflows, allowing us to scale our underwriting, policy processing, and high-volume claims handling independently of our application’s compute resources, crucial during CAT events.

• Observable: Every workflow execution has a complete, queryable event history, making it incredibly easy to debug, audit for compliance, and understand the real-time status of any policy application, claim, or billing event from initiation to completion. No more playing detective with fragmented logs; the full story is always there.

Legacy services migration

Migrating the intricate, stateful processes within our legacy RDBMS based applications to Temporal typically involves identifying and extracting the core business processes currently orchestrated within the database and application code. Here’s our conceptual approach:

• Identify Core Workflows: We analyzed our existing systems to pinpoint sequences of operations that represent a complete business process (e.g., “New Policy Application, Underwriting & Issuance,” “Claims management,” “Premium Billing & Collection with Payment Plan Management,” “Policy Endorsement & Mid-term Adjustments”). These are our prime candidates for Temporal Workflows.

• Decouple and Extract Logic:

  • Stored Procedures/Triggers: We converted the complex business rules and data manipulation logic embedded in the stored procedures and triggers into independent Temporal Activities. Activities are typically short-lived, idempotent operations that interact with external systems, like our existing database, other microservices, or third party APIs.

  • Application-Level State & Orchestration: We replaced the application code that manages policy or payment or endorsement state in database tables often with complex status machines and polling loops with Temporal’s durable workflow execution.

• Define Temporal Workflows: We wrote our core insurance processes as Temporal Workflows using Temporal’s Java SDK. Our Workflow code would orchestrate the execution of Activities, representing the steps of our insurance process.

• Implement Temporal Activities: We created the Activity implementations that encapsulate the specific actions. These Activities contain the actual calls to our database (e.g., updating policy statuses), interacting with legacy systems via APIs (e.g., integrating with existing policy admin systems or billing platforms), or connecting to new microservices (e.g., High Definition property pictures).

Example: policy payment processing workflow using Java

Temporal Batch Iterator pattern for large-scale data processing

One of the most challenging aspects of migrating our legacy insurance systems is dealing with vast amounts of existing data that needs to be processed, for example, monthly statement generation. Traditionally, this involved complex, fragile batch jobs, often orchestrated via database agent or custom scripts, which are prone to failure and difficult to monitor.

Temporal’s Batch Iterator Pattern provides a powerful, durable, and observable way to handle these large-scale data processing tasks. Instead of trying to process a large dataset within a single, long-running workflow, the pattern works as follows:

• Orchestrator Workflow: A main “Orchestrator” Workflow is responsible for:

  • Querying our database via an Activity to identify a batch of records to process.
  • Spawning a separate Child Workflow for each individual record or small group of records within that batch e.g., one child workflow per policy payment record.
  • Maintaining its own state to track which batches have been processed and to aggregate results from the child workflows.

• Child Workflows: Each Child Workflow handles the processing logic for its specific record. These child workflows benefit from all of Temporal’s durability, fault tolerance, and retry capabilities.

• Durable Iteration: If the Orchestrator Workflow or the Activity querying the database fails, Temporal ensures it resumes from the last known state. It won’t re-process records that have already had child workflows spawned for them, and it can pick up the next batch seamlessly. This significantly increases the reliability of large-scale batch operations that were once a source of significant operational overhead.

The Batch Iterator pattern is ideal for tasks like:

• Mass Policy Renewals: Spawning a workflow for each policy due for renewal, managing complex premium calculations and endorsements.

• Statement/Billing Cycle Generation: Creating a workflow per customer to generate their annual statement or manage complex installment billing..

• Data Migration & Transformation: Processing millions of legacy records to migrate them to a new system or format, ensuring each record is processed durably.

• Regulatory & Compliance Reporting: Generating individual reports or performing checks on a large number of entities.

Sequence diagrams illustrating the Batch Iterator Pattern:

Explanation of sequence diagram 1

1. A user or an application kicks off our main “Orchestrator Workflow”.

2. The Orchestrator Workflow runs in a loop. In each iteration, it calls an Activity, executed by an Activity Worker.

3. This loadData Activity interacts with the database to fetch a defined “batch” of records, often using pagination.

4. Once a batch is received by the Orchestrator, it then, for each record in that batch, starts a Child Workflow.

5. Each Child Workflow is a separate, independent, and durable execution that handles the specific processing for that single record.

6. The Orchestrator maintains its internal state (like lastProcessedId) to ensure that if it fails and restarts, it knows where to resume fetching the next batch without duplication.

7. The loop continues until no more records are found in the legacy database.

Explanation of sequence diagram 2

1. This diagram shows a detailed view of what happens within a single Child Workflow (e.g., Payment Processing Workflow).

2. It orchestrates a series of Activities like processing a payment or sending email communication..

3. Each Activity interacts with an external service – here, our PaymentProcessingService and EmailService.

4. Temporal’s built-in retry mechanisms would handle transient failures for any of these Activities, ensuring the overall policy payment or email communication processes are robust

5. Upon completion, the Child Workflow’s status is known by the Temporal Server, which can be observed by the Orchestrator.

Key benefits of Temporal in SageSure’s modernization journey

• Reliability & Durability: Temporal guarantees workflow execution to completion, even if our systems crash. This is crucial for financial integrity, regulatory compliance, and maintaining policyholder trust.

• Simplified Complexity for Business Logic: Complex retry logic for external integrations, long-running processes, and compensation patterns are built into Temporal’s programming model. This significantly reduces the amount of fragile, boilerplate code we need to write and maintain.

• Improved Scalability: Decouple our core business logic from database contention. Temporal scales horizontally, allowing us to handle a massive number of concurrent policy applications, complex billing cycles, ensuring responsiveness and operational continuity even during peak demand.

• Accelerated Product Innovation: We can write complex insurance processes as clear, imperative code. The clean separation of Workflow and Activity logic makes it easier for our product managers, and developers to quickly design, test, and deploy new insurance products, adjust commission rules, or modify existing claims processes to respond to market changes.

• Future-Proofing Tech: We can move away from a monolithic, tightly coupled design towards a more distributed, microservices friendly architecture, paving the way for advanced geospatial analytics, AI-driven risk assessment, real-time data integration, and other future modernization efforts crucial for a leader in the Insurance Tech space.

Conclusion

Migrating our core workflows from legacy RDBMS based applications to Temporal was not just about fixing immediate problems; it was about transforming the fundamental way SageSure operates. It liberated our critical business logic from the confines of outdated architectures, allowing us to innovate faster, improve customer experience, reduce operational risk, and build systems that are ready for the demands and evolution of the modern Insurance Tech landscape.

Constant management in AP

A good constant should have at least the following characteristics

1. It stores fixed values that have been used multiple times in different places in the codebase.
2. It has a meaningful name. Usually the name describes the purpose of constant or the data they represent.
3. It has a scope.
4. It has a specific data type.

As a result, I get a React functional component that uses TypeScript. Here are the type annotations that I added. They clearly indicate the types of each prop.

This is also a guide in AP when we create a constant. In AP, we manage constants from two scopes: global and local. Global constants are usually shared in different components, and local constants are usually for first level or second level components. All constants are started as a local constant, and the name convention for the constant file is <component-name>.constants.ts

At global level, there is a file called constants.ts that imports and exports all local constants files, which makes it easier to share local constants across the components. This global constant file also contains project level constants which clearly the scope is global.

The pros of this strategy is that it’s easy to locate constants and all constants are rooted from one place. This approach also simplifies updates and modifications.

The cons is that it requires a clear and thoughtful categorization scheme. Be Careful when introducing the new constants, and give it the right scope.

Other strategies to manage constants

1. Centralized Constants File:

Pros:

• Easy to locate and manage constants in a single file.
• Enhances consistency as all constants are in one place.
• Simplifies updates and modifications.

Cons:

• Can become overwhelming as the codebase grows.
• May require careful organization and categorization to maintain readability.

2. External Configuration:

Pros:

• Allows for configuration adjustments without modifying the code.
• Useful for constants that change based on different environments (e.g., URLs, API keys).
• Separates concerns by keeping configuration separate from application logic.

Cons:

• Introduces external dependencies and potential configuration errors.
• Might lead to confusion if not well-documented or version-controlled.

3. Using Frameworks or Libraries:

Pros:

• Leverage established practices and patterns for managing constants.
• Frameworks may provide additional tools for validation, configuration, etc.

Cons:

• May introduce a learning curve for using the specific framework.
• Could lead to unnecessary dependencies if not carefully considered.

4. Application-Specific Constants Classes:

Pros:

• Encapsulates constants within classes, offering better organization.
• Provides a clear naming convention by using class namespaces.

Cons:

• Might introduce additional complexity for small projects with limited constants.
• Requires adherence to the class-based approach throughout the codebase.

5. Enums (Enumerations):

Pros:

• Provides a clear and expressive way to represent related constants.
• Enhances type safety as enums restrict values to a predefined set.
• Reduces the chance of using arbitrary integer or string values.

Cons:

• Limited flexibility in cases where the values are not enumerable.
• Adds some complexity when compared to simple numeric or string constants.

6. Database or External Storage:

Pros:

• Offers the flexibility to change constants without redeploying the application.
• Useful for frequently changing values or for non-technical users to manage.

Cons:

• Introduces performance overhead when fetching values from an external source.
• Can complicate deployment and version control, especially in distributed systems.

Conclusion

In conclusion, there is no one-size-fits-all strategy for managing constants. The best approach depends on your project’s size, complexity, team dynamics, and future scalability requirements. A combination of these strategies might be necessary to strike the right balance between maintainability, readability, and flexibility. Whichever strategy you choose, ensure that your team is aligned and that the chosen approach is well-documented to facilitate seamless collaboration and future development.

My Refactoring Process

I needed to update the code that was written using the old style of react class components. For example, the component “SearchableText” is written using the React class component.

1. Convert the code to use React functional components. Going through the process of updating the component helps me to understand the code.
2. Console log the component props to confirm their types. This step can be a challenge sometimes. For example, if a component has a prop that is a > child prop passed from a parent component, then I need to track down the parent component to figure the types.
3. Use command git mv \***.js **\*.tsxto rename the file to use the.tsx extension, which supports TypeScript. Using git mv is important for Git to automatically detect the rename and update the history accordingly.
4. Add TypeScript type annotations and Interfaces. The challenge of this step is to understand the codebase and determine the appropriate types for variables and functions. Sometimes, bugs will be revealed in the code as I add type annotations. Fixing these bugs as they crop up can be time-intensive.
5. Run unit tests and update unit tests accordingly. This step helps me guarantee that the refactored code is still valid and can run successfully.

As a result, I get a React functional component that uses TypeScript. Here are the type annotations that I added. They clearly indicate the types of each prop.

What I Learned About TypeScript While Refactoring

• Using TypeScript helps catch potential bugs. For example, the following function will not show errors in JavaScript.
  
  

  

  
  But if we write with TypeScript support, the type error will be caught.
  
  

  

  
  
• Using TypeScript improves code readability. Type annotations make the code more self-documenting, and I can immediately understand what types of values the function can accept and return. For example, in the following code, it’s clear that setPage is a dispatch action.
  
  

  

  
  
• Using TypeScript improves handling of null and undefined . For example, the following JavaScript code might return null or undefined in the case of invalid inputs.
  
  

  

  
  Using TypeScript allows me to specify the type annotations for function parameters and return values. In this case, the function is explicitly defined to return either a `number` or `null`, providing better clarity about its behavior.
  
  

  

  
  

• TypeScript’s type system catches potential errors early in development. If I accidentally use the result variable without checking for null, TypeScript would raise a compilation error.

• Interfaces can define the structure of an object, specifying the properties and their types. This aids in creating contracts between different parts of the codebase and promotes code reusability.

• TypeScript also can infer types based on context, even if types are not explicitly specified. This reduces the need for explicit type annotations while still providing type checking.

• TypeScript can work with existing JavaScript libraries by using type declarations or type definition files (.d.ts files) to provide type information for JavaScript code.

• TypeScript supports union types (values that can be any one of multiple types) and intersection types (values that must satisfy multiple types simultaneously).

Learning Through Practical Application

It is hard to acquire new knowledge without applying what you’re learning. The refactoring process is a great opportunity to learn about TypeScript. Instead of just reading documentation and practicing using example code/code playgrounds, refactoring is a real world application. Every challenge that I encountered during refactoring was helpful to make the learning process more natural.

Conclusion

Technology develops fast and refactoring will keep a product alive and more competitive in terms of performance. I am a fan of refactoring not just because I personally benefit a ton from it, but also due to the benefits of having high quality code and better performing projects. Having a habit of refactoring code is a double win.

In summary, there are many ways to acquire programming knowledge, and I find my best and favorite way is through refactoring. AP is a perfect project for me to keep improving my programming skills, allowing me to enhance my knowledge during refactoring. The knowledge that I gain through refactoring is long-term knowledge, because I was able to not only learn about new topics but to apply it to the AP project.

Some observations

Agile methodology teaches us that the daily scrum is 15 minutes, where each member of the team shares what they did yesterday, what they will do today, and if they have blockers. No more and no less.

This is the methodology, but Agile needs to be flexible to live up to its name and purpose. Now that Software teams have become more hybrid and co-located, the daily scrum can be repetitive and boring, causing team members to lose investment in the meeting. The heart of scrum can remain: a team update and work progress touchpoint, but the format needs to be willing to change.

• Yesterday’s update. If a team is working very closely together, they already know what the members did yesterday. They were most likely doing the work along side each other. If your team is working in lock step, I would recommend completely eliminating the portion of scrum where each member reviews what they did yesterday.

• 15-minutes. Working from home means less watercooler time or less casual conversion when people arrive in the office, or mingle around lunch. Invest in your team and don’t restrict the meeting to 15 minutes. The extra time can be used to further discuss blocking issues, or share upcoming weekend plans.

• Person-by-person. Variety can create a higher engagement level from the team members. Some teams prefer person-by-person (traditional) updates during the stand-up, allowing everyone to speak and share their progress. Other teams opt for a Split plan stand up, discussing initiatives one by one. When speaking through initiates, assigning one person to be a primary owner, or champion, is valuable. This ensures that no single person dominates the entire meeting and helps reinforce which team member is the primary contact for that initiative. Some teams mix and match these update styles. Some days, they go by person, and some days, they go by initiative.

Better practices

Whichever style you adopt, here are some practices I would encourage.

• Sharing your camera during Scrum is a good thing because it promotes stronger team connections and enhances communication. Visual cues and body language play a significant role in understanding and interpreting messages, fostering a more empathetic and collaborative environment. By enabling team members to see each other, it encourages active participation, engagement, and accountability during the meeting, leading to more effective and productive discussions.

• Giving each person an opportunity to speak during Scrum is a good thing because it ensures that all team members have a chance to share their progress and challenges, fostering a sense of inclusivity and ownership within the team. It also prevents the dominance of certain individuals, promoting a more balanced and diverse input during the meeting.

• Engaging blockers—it’s essential to prioritize and discuss blockers each scrum. Is something preventing a work item from progress? Discuss the problem and appoint a person to be responsible to track it down!

• Varying the order of speakers during Scrum is a good thing because it prevents the meetings from becoming predictable and encourages all team members to stay engaged and attentive. It also ensures that different perspectives are heard, leading to more diverse insights and fostering a collaborative team environment.

• Setting aside time to talk about life during a remote team Scrum is beneficial as it fosters stronger connections, builds trust, and promotes a supportive and empathetic work environment. This can be once a week for 10 minutes. It can a prepared topic or informal, like a “how was your weekend?”.

• Wins, wins, wins! Delivered a feature? Celebrate it! Call it out and have the team recognize the achievement. A celebration doesn’t have be a pizza party. It can take a minute or less the daily scrum. Pizza parties can still be done, but don’t fit every delivery or accomplishment. Did the team perform well in a debugging session? Did an individual have a great insight? Is it someone’s work anniversary? Build and maintain a team that celebrates their deliveries and its team members!

Further enhancements

• On the subject of documentation, teams have the option of documenting their updates or not, and it’s essential to find the right approach that works for your team. Some teams benefit from detailed documentation, while others prefer a more fluid and verbal approach.

• Color coordinating and categorizing the split view based on areas of work (backend, frontend, design, product, etc.) can be beneficial as this visual organization makes it easier for team members to understand the distribution of work and responsibilities. In addition, returning to this page during the week can help members understand their work and its status at a high level.

• Giving each week a theme name inside the split, such as Texas Hold ‘em’s betting stages, can make the process more fun and engaging for team members. The betting stage convention can also give an idea of how mature the Initiatives should be at that time during the split.

• Finally, it’s a good idea to open the floor for demos, allowing teams to showcase their progress and achievements during the sprint. Demos not only provide an opportunity for the team to showcase their work but also encourage collaboration and feedback. Attending a demo of work you’re not directly involved with can also help deepen and broaden the knowledge base of the entire team.

Making scrum work for you

In conclusion, the key to successful Scrum implementation is to mix things up and not shy away from trying new approaches. There are some best practices, like sharing your camera, but beyond that each team is unique. Experiment with different meeting styles, themes, and communication methods: be adventurous! After trying something new for a few meetings, gather feedback from the team to assess whether the change is beneficial and should be kept or not desired and should be abandoned. Continuously learning from these experiences will help your team refine its Scrum practices and create a more efficient and productive workflow.

Happy Scrumming!

After four years at SageSure, I backed up from a job that I loved because I fell victim to burnout and left the very company where my career in software began.

SageSure gave me what I felt was my first big break into the software world. It was the kind of job that I had been reaching for since I graduated college: remote work, a handsome salary, incredibly talented coworkers, and doing exciting work. It was a dream come true. The first few years were fast-paced and exciting and I genuinely loved the work that I was getting to do. A year after coming on board I had assumed the role of Operations Lead with a small team of talented engineers overseeing our Cloud infrastructure, CI/CD systems, and being responsible for monitoring our production stack. As a company, we were accelerating at an amazing pace and smashing records for new business nearly every month. As a result, the frequency of changes and deployments flowing into production was ever-increasing. On one hand, I was watching my career take flight all while learning new tech and automating everything else. On the other hand, the number of backlog tickets, production incidents, outages, and postmortems that I was participating in was ever-increasing. At times I felt the crunch and hunkered down to get through tight deadlines, incidents, and an endless number of meetings. But still, I loved my job.

At this point, the quiet erosion of my career euphoria, my dream job, was hardly noticeable. There were times when I directly felt the stress of work but I always assumed that you sometimes felt exhausted from work and that was it. I figured if things got really bad I could take a few days off to reset. Another year went by and the story reads the same: more organizational success, more frequent delivery to production, and more fallout from outages, technical debt, and new features. Then, I finally hit a wall. The thing is I didn’t hate my job at this point, I still loved it, but I knew that it was going to crush me if I didn’t leave it behind. I felt powerless and ill-equipped to handle the way that I responded to stress. I was out of gas and had no more energy left in me to give to my job, so I resigned and slipped away with a bag of emotion dragging behind me.

How did this happen? Why didn’t I see this coming? These were the questions that swirled in my head when I finally had a chance to reflect on the most shocking turn of my young career.

What exactly is burnout?

Stress manifests in everyone differently and can make identifying and treating job-related stress and burnout a real challenge. Herbert Freudenberger, a German-born American psychologist and psychotherapist, first coined the term “burn out” in 1974 describing it as “a consequence of excessive stress leading to chronic fatigue and lack of enthusiasm”. His work defined a 12-stage model for the development of burnout symptoms:

• The Compulsion to Prove Oneself - Demonstrating worth obsessively, probably something that’s especially prevalent in tech/software where imposter syndrome can be a factor
• Working Harder - An inability to switch off, working late, working early, working on your days off
• Neglecting Needs - Neglecting your own needs. Poor sleeping habits, disruptive dietary changes, reduced social interaction
• Displacement of Conflicts - Displace the acknowledging that you’re pushing yourself too much and instead you blame your manager, the demands of your job, or coworkers for your stress
• No Time for Non-Work - Revision of Values; where work can become your only focus and your personal life is de-prioritized
• Denial - Impatience with others begins to mount and instead of taking responsibility for your feelings you start to form intolerance and cynical attitudes towards coworkers, clients, and your manager
• Withdrawal - Complete withdrawal from family and friends and your social life
• Behavioral Changes - Obvious behavior changes, things that your friends and family may take notice of. Those that are on the road to burnout may become aggressive or snap at friends and family for no reason
• Depersonalization - A reduced or lack of sense for personal accomplishment, detaching yourself from your work, and feeling like you’re no longer valuable
• Inner Emptiness - Feeling empty and anxious
• Depression - Exhaustion, and feel like the future is dark and bleak
• Burnout Syndrome - Which he describes as a total collapse

Many of these are clear sensations that may be easy to spot yet others you may never realize until you’re in the middle of it. In my case burnout first began building early on in my career at SageSure but not in ways that I ever expected or even noticed.

What I learned

• We often talk about burnout when it’s too late It feels a bit edgy to open up about all of this which I think points to one of the inherent issues with burnout in the modern workplace: it’s unnecessarily regarded as taboo. No one really wants to talk about stress and burnout. The thing is, no one is immune to the symptoms of burnout either, and everyone endures stress in the workplace whether they know it or not.

• Burnout is as slippery as it is silent I never noticed that my burnout was as bad as it was until it was too late. It creeps up on you, ever so slightly, so you don’t come to notice that you’re suffering more and more each day. You generally won’t notice the signs of burnout in yourself because it’s a gradual thing, affecting you little by little over a period of time.

• I didn’t know how to step away I pressured myself into working long hours, working late, and through my lunchtime regularly. In addition, I didn’t take advantage of some of the resources that SageSure provided me, like paid time off. I remember looking on my last day of work I still had 84 vacation hours of unused time. Because I spent so much time focusing on my work, I didn’t spend enough time paying attention to myself and as a cause, I didn’t recognize my burnout until it was way too late. Instead of stopping to defuse the ticking time bomb I kept pushing forward and let it grow bigger and bigger.

• There’s a razor-thin edge between loving your job and feeling destroyed by it I loved my work, and as such, was more prone to burnout. It’s one of those ironies of having a career. It’s like a complicated love affair: some days it’s exciting and passionate while other days it’s exhausting and emotionally draining. It’s easy to work longer and harder when you’re passionate and invested in your work but, as most things go, it requires careful balance with time away from the job. Without balance, you will most certainly be crushed.

SageSure, round two

After I burned out I spent the following year and a half freelancing and working on personal projects which gave me the opportunity to reflect on what happened and why it happened. I stayed in touch with SageSure and my friends there and was lucky enough to get the chance to join the organization for a second time with a new perspective on my job and priorities. Better understanding burnout and how job stress affects me has made a significant improvement on my quality of life and the quality of my work.

Conclusion

If there’s any takeaway you get from this post it should be this: talk about burnout. It’s the most important first step anyone and any organization can do. I’m a testament to the reality of work stress and burnout and wanted to share what I know about it, what I went through, and to hopefully get us started on thinking about these things more often.

SageSure offers dependable homeowners insurance in catastrophe-prone areas where it’s needed most. We are an innovative insurance company that promises stability, peace of mind, and a commitment to being there for the long haul.

SageSure partners with many highly rated insurance carriers to serve the various needs of our markets. But what makes us stand out is that SageSure actually designs, develops, and files our proprietary homeowners and commercial insurance products ourselves.

Our approach combines the benefits that the carrier, underwriter, and distribution partners bring into one solid effort—and the result is unwavering, long-term support that agents, homeowners, and business owners can depend on.

The SageSure software team and Postman

The SageSure software team is focused on improving our development and delivery process. One high-priority process is continuous delivery of new features. This means no service downtime during deployment, and frequent small pushes to the production environment with a high level of confidence. This end-to-end deployment effort is realized with the help of many tools, including the Postman Collection Runner for test validation.

SageSure’s tech stack including the Postman API Platform has resulted in these key benefits:

• approval of merge requests to production in under 60 minutes;

• increased frequency of smaller deployments;

• a high degree of confidence with regression functionality; and

• enhanced reliability of services at the micro level.

Common deployment concerns

The questions our team assessed while looking to improve our process include: How do you get the code that is adding a feature or fixing a bug into a live environment? What team members are involved in the push? At what time does the push take place? Do you have a high degree of confidence that this new feature/fix will not break any current functionality? Does deploying cause any downtime for the user?

Companies have varying answers to these questions. As one example, some companies do quarterly deployments. But this typically leads to mountains of code for that release date and may mean that some projects are shipped incomplete because they needed to meet the deploy window but weren’t actually ready to ship. Here, some bugs get resolved, but other bugs are created due to the massive volume of code shipped and all the moving parts involved. Then, if a bug isn’t deemed important enough for a hotfix of some sort, that bug has to wait for the next quarterly deployment. This process often means more pains to address—pains for team as well as for the user.

While we never had quarterly deployments, we were working with a cumbersome deployment process. As part of our ethos of customer-centricity, continuous improvement, and the assessment I mentioned above, we arrived at the following approach.

The SageSure solution

Once a code change is approved through a merge request, many different test suites are run and, when they pass, the code is pushed to production without any service downtime. Deployments happen frequently—as often as code is merged; it’s not unusual to have three or more production deployments per hour. These deployments could be in different areas of our software: a UI enhancement here, a backend integration there, a bug squashed over there.

Testing testing testing

The beauty of frequent small deployments is that each package is validated through each level of testing. We have automated unit tests, automated helm tests, automated UI tests, and automated Postman tests. Each suite verifies the new functionality, and also verifies no previous functionality has been altered or removed unintentionally. Pushing with confidence!

Each test suite is designed to test specific aspects of our software product. Unit tests confirm the behavior of the smallest testable parts of our code. Helm tests verify the server spun up correctly. Postman tests verify API functionality, both internally and with external partners. UI tests verify E2E paths are on their best behavior. The test after the server has launched is not yet accessible by live users; it is spun up in preview mode. Only after each test suite passes, is the new server then given traffic and the old server is spun down and no longer given live users.

The Postman test suite

This specific test suite attacks a unique problem: external and internal dependencies. With a validation suite collection in Postman, we can verify services are connected to an application in each environment as the pipeline progresses: database connection, internal DNS address routing, authentication, security, application to application connectivity, and third-party integration verification—to name a few. These tests are vital to ensure the application is up and able to communicate with other internal and external dependencies required to perform accurately. These tests are also designed to swap out environmental conditions and values. In a lower environment, we can verify connectivity to a test third-party endpoint, while the upper environment will verify the corresponding endpoint.

Going forward

SageSure has eliminated a tremendous amount of manual, repetitious work by investing in an advanced deployment pipeline. In doing so we’ve also managed to deliver with greater confidence for ourselves and in the experience of the user: no down time, and less bugs.

If a bug does get through, our process is to write a test that fails in the area where the bug exists. Is it a backend issue? Write a Unit test. Is it an E2E mismatch? Write an automated UI test. After the test suite has been updated to look for this case, we fix the bug and run the pipeline. Now, because of our investment in the test suites, we can be sure that:

1. we fixed the issue;

2. we did not introduce a different bug; and

3. this bug will not happen again in the future.

With this approach, we’ve been able to apply fixes to production issues in less than 60 minutes after they were discovered.

In short, this continual investment in our pipeline validation gives us more confidence with each iteration—more confidence, and a better experience for our users.

Delivering with confidence

Continuous delivery requires great confidence. Once achieved, it improves the quality of life for members of our development team. More regular working hours. Less stress on deployments. Less red tape. More backyard BBQs and weekend water park adventures. Getting here was more than worth it, and we have our excellent team to thank—as well as Postman.

This article has also been published here.

However, once SageSure’s design system initiative began in earnest and all three were closely evaluated, it was clear the products deviated from each other in a number of important ways, leading to inefficiency and confusion.

A shared philosophy

SageSure’s digital team began to realize that even though the three products had unique purposes, they shared enough in common that unifying and componentizing their building blocks would increase team velocity as well as reduce ambiguity during the transition from design to engineering. So we set about creating a system based on atomic design principles that would provide our teams with a common vocabulary and help them build features with a shared philosophy.

With three unique experiences to consider, we had to ask ourselves: can these apps in fact be unified in both design and code? Should they? What are the advantages? Is it a good use of our time? We began to explore the trade-offs involved.

One of the conclusions was that, even though our current products have three siloed audiences that would unlikely experience the unification effort, SageSure’s designers and engineers would benefit greatly and a unifying system would help validate our design principles at scale. Additionally, the workflows of our traditionally-siloed audiences are increasingly overlapping, necessitating a system to help deliver a coherent, unified experience to all our customers.

Piecing it all together

The first step was doing an audit of the three products and making note of all the visual similarities and differences. Focusing first on simple foundational elements such as color, spacing, and typography, we explored the possibilities and ultimately found middle-ground solutions that would work in all three contexts without causing disruption to the existing UI.

That process also helped us codify simple guidelines (ex: use the fill/active color token for navigation states) so that designers would always understand what to use and when, regardless of the product.

From there we designed more complex pieces (ex: buttons, dropdown menus) that had easily identifiable purposes while also being visually broad enough to work seamlessly in all three products. One at a time, we staged them in Figma and discussed their variants and states along the way. Each one was then coded, added into Storybook, QA’d, and released to the teams to begin integrating them.

Bit by bit, we tied our products together using Storybook as a centralized source of truth. The process also helped us define a contribution model for creating new components.

A holistic product

One important note: until recently, many companies have defined “design system” as a simple UI kit for designers to prototype features. At SageSure, we consider the beginnings of our system to be a holistic, overarching product with three crucial touch points—a UI kit in Figma, a Storybook site where components are consumed, and a documentation site for guidance around usage (as well as serving as a great onboarding tool to help new employees understand the principles upon which we built the system).

Building a design system for multiple products can seem daunting and there are challenges to keeping everything aligned. But purposeful, well-defined global styles and proper tokenization glueing things together has helped our teams build applications with increasing confidence and clarity.

I shared what I view as the four key elements that drive retention that you should be actively considering if you‘re in a leadership position on a technical team:

1. Connectedness. Ensure a connection for each team member—to the company, to the strategy, to their manager, to their work, and especially to their team.
2. Agency. Cultivate the voice for tech talent—for their work, their career progression, their tooling, and the processes used by the team. And listen to this voice.
3. Growth. Ensure your technical team members have opportunities to grow and the support to make that happen.
4. Modernity. Top tech talent wants to work on modern tech with modern processes and practices and be able to be current with the goings on in their discipline as well as industry. Is yours modern?

.@timothymeaney explains how fostering connectedness can be powerful strategy to retain talent: https://t.co/MZaAB7KczO pic.twitter.com/dYRyia07UJ

— Postlight (@Postlight) January 6, 2022

Effective Product Design is a cascading series of trade-offs. There is no right, no wrong, there’s only trade-offs. – Tim Meaney, VP of Software at SageSure

At SageSure, our software is not the product we offer our customers. It’s a means to an end, a tool our customers use to gain access to our core product: insurance built on continuous capacity and long-term financial stability.

That is what we aim to deliver our customers. It just so happens that software makes that happen.

The faster we can build quality, effective software, the faster we can deliver to our customers.

One trade-off: useful software over creative expression

Over the last few years the software team at SageSure had developed several threads of systematic design—style guides, pattern libraries, and components—which have together constituted the building blocks of our varied digital products.

These threads of systematic design were loosely defined and controlled, in turn granting broad freedom and creative interpretation to individual team members. And while the discrete threads were consistent in themselves, the assembled whole often was not.

But given the nature of our organization—its size, structure, and resources—the trade-off of consistency around narrow sets of patterns at the expense of the whole, and individual creativity at the expense of cohesion and team velocity, worked.

Until it didn’t.

We had freedom and a sense of creativity in assembling the building blocks, but our teams felt an ever-growing desire to relinquish that kind of freedom in exchange for increased clarity and velocity. We wanted to ship more useful, quality software to our customers over being more individually expressive.

This was one of the key trade-offs we documented in assessing our needs to build a design system.

Resources are finite for our team. We wanted to leverage this constraint as an advantage, allowing necessity and creative constraints to be the mother of invention.

Trade-offs

The word “trade-off” can carry a negative connotation in software. Rich Hickey points this out in his talk “Hammock Driven Development”:

Everybody says design is about tradeoffs. Everybody knows this. Usually when they talk about tradeoffs in their software, they are talking about the parts of their software that suck. “I had to make these tradeoffs.” That is not what a tradeoff is, right?

You have to look at, at least, two solutions to your problem. At least two. And you have to figure out what is good and bad about those things before you can say, “I made a tradeoff.” So I really recommend that you do that. And when you do it, you might want to write that down somewhere.

Given a small team and a small organization, we can’t create a system like Material Design from Google or Lightning from Salesforce.

Then again, why would we want to? Their design systems are solving an entirely different set of organizational problems than we are.

This is why it is so critical to pinpoint what you want to accomplish and then, per Rich’s advice, document the trade-offs you’re willing to make to get there—because there will be some!

Understanding the trade-offs you’re willing to make helps guide your decision making and reveals your priorities. It’s similar to principles where you state X over Y, but with a trade-off it can be X instead of Y. If you don’t acknowledge that limitation, that trade-off, you’ll mistakenly think you can have both. Only later will you realize the universe isn’t so generous.

Surface and document your trade-offs now

Consider again the quote that began this article from Tim. I’m going to swap out “Product Design” for “design systems” and I think it still holds:

[a design system] is a cascading series of trade-offs. There is no right, no wrong, there’s only trade-offs.

The faster you understand the needs of your organization and the outcomes you want in service of your customers, the faster you can state, document, and make the inevitable trade-offs that come with creating a design system.

You’ll have to make trade-offs in creating a design system sooner or later. If you make them later, you’ll suffer from them longer. Better to document and make them sooner.

Approximately six years ago, all of our services were hosted on Windows virtual machines in a data center with Microsoft’s Internet Information Services (IIS) and Apache. Deployments were performed manually by operations engineers and involved copying files received from developers to multiple VMs. When I joined SageSure in 2015, the DevOps team was already working on a project to dockerize all services and automate the deployments. After many months, and a few iterations on the architecture, we ended up with a more modern setup: dockerized services running on linux hosts deployed using automation from Jenkins.

This setup provided us a number of benefits:

1. Deployments were automated, reducing time and errors associated with deployment.
2. Build artifacts were immutable and generated with each release. Every commit to a releasable branch generated a docker image that could be deployed to any environment for testing.
3. Scaling was easy. Instead of provisioning a new vm, we just needed to click a ’+’ button in Rancher, our Docker orchestration UI.

And this worked great for us. During this time, we were also migrating our services from the data center into AWS. The new dockerized setup made the move a lot easier.

Lingering pain points

But as the years have gone by, even as we enjoyed the benefits of our new architecture, we noticed a few weaknesses, particularly for our websites. Our routing layer relied on polling internal DNS to resolve the container IPs. As a result, every deployment had a small window (a few seconds, usually) where requests could fail if the old containers were destroyed before the proxy found the new containers.

Additionally, our frontend teams asked for the ability to preview a build for each feature branch before merging into the mainline. Thanks to our Docker architecture, we were able to add this functionality pretty easily by deploying the dockerized build and leveraging wildcard subdomains in DNS. However, this meant that we were now running dozens of copies of our frontend apps at the same time in our integration environment. Even with reduced memory reservations, we frequently ran out of capacity and had to scale up the cluster, or manually review and delete a large number of stale feature branch builds.

Lastly, running the websites within our own Docker infrastructure and behind our own proxies meant that any downtime or CPU contention in the cluster had a very visible impact to our users. Also, we weren’t doing anything explicit to manage the caching of website assets, so we would often have to instruct users to clear their browser cache if they were having issues after a deployment.

So it was time to evolve our architecture once again.

Implementing a static site architecture

Our new architecture is based on AWS’s whitepaper for hosting static websites in AWS

In summary, the architecture consists of:

• An AWS S3 bucket to hold variations of the website (to support blue/green and preview deployments)
• AWS CloudFront distributions to serve as a CDN and cache-management solution
• AWS Application Load Balancer (ALB) to serve traffic to CDN or API
• AWS Web Application Firewall (WAF) to provide Geo/IP security restrictions to the CloudFront content
• A lightweight reverse proxy for API routes

Routing requests to the APIs

One of the key factors to consider in the new design was how we would route requests made by the website to a backend API. For all of our websites, the backend APIs were paths on the website domain (e.g. https://app.example.com/api) instead of on a dedicated API subdomain (e.g. https://api.example.com). Changing this would have ballooned the scope of the project, so we were left with handling the routes on the same domain. In practice, that means a request to the website domain could be intended for a backend or for the website itself, depending on the path. We used a lightweight reverse proxy to direct API-bound traffic to the appropriate backend service and route all remaining traffic to the webserver.

Moving forward, we had a few options for how we would split traffic between the CDN (taking over the job of serving the website assets) and the API backends:

1. Put our reverse proxy inline, in front of the CDN. This would mean our proxy instance and docker infrastructure are still in the data path, but requires the least amount of change.

2. Split traffic at the ALB layer using path-based routing. Ideally, we could collapse all backend routes to a common /api/ base to ease the routing configuration.

In the end, we decided to think of these as phases instead of competing options. We were able to deploy the first option quickly with minimal changes by leaving the API routing untouched. Once our websites are all migrated, we plan to implement option 2 and update the API routing to remove our proxy as a dependency of accessing the website.

Deploy process

The updated deployment process now works as follows:

1. For each deployable build, the pipeline job compiles the static site and saves the bundle as an artifact.
2. The bundle is synced to the environment s3 bucket under a versioned folder.
3. For stage preview environments, the reverse proxy will take care of routing to the correct folder based on subdomain (No CDN is used for stage previews).
4. For production preview, a post-deployment script will update the preview CloudFront origin to point at the new folder and perform cache invalidation, as required.
5. Once the prod preview has been accepted, a second job will be used to update the production CloudFront origin to the new folder and perform cache invalidation, as required.

Notes:

• The active distribution files are never directly modified during deployment. This keeps each build immutable and available as a target for fast rollback.
• An alternative would be to use stable CloudFront origins (in blue/green style) and use either:
  • DNS to switch between the active distribution. This, however, would subject users to DNS propagation delays.
  • Weighted routing to use a single DNS entry against a blue/green CloudFront distribution. This would require maintaining blue-green state in the deployment script and preview routing to ensure the correct version is updated and enabled.

Conclusion

We migrated a major internal website to this new architecture late last year and it has been running in production without issues for the past 9 months. Our internal team has enjoyed the fast updates, the flexibility to deploy more often without user impact, and the increased number of available preview environments. We’re in the process of migrating our public websites to the new architecture so those teams can enjoy the same benefits.

Our CICD goal: All Merge Requests should be capable of being released in less than 60 minutes.​

This post is about why we want to move to CICD, the challenges we need to overcome, and how we will know we’re succeeding.

Current state

Currently we deploy to production about once a week for most projects. More frequently for our backend services, less frequently for our frontend apps. Our deployment frequency and lead time metrics both reflect this:

Why move to CICD?

There are 3 main reasons for us switching to CICD:

• Faster feedback
• Reduce the cost and risk of release​
• Create a better place to work!

Faster feedback

Are we we delivering the right thing to our customers? In his 2012 Continuous Delivery talk, Jez Humble pointed to a study by the Standish Group that looked at the features used in applications, which found that

• 20% of features are often used
• 30% of features get used sometimes or infrequently​
• 50% of features are hardly ever or never used

Half of the features that get developed being rarely ever used is a shocking statistic. Writing software that our customers don’t even want or use is a huge waste​.

How do we reduce that waste? Lean principles suggest that we figure out how to build the smallest thing that would allow us to validate a hypothesis, and optimize for a build-measure-learn feedback loop. Listen, hypothesize, build, get feedback, iterate and repeat.

We want to optimize our software delivery process for time around this loop​. And Lead Time​ is a key component of this cycle.

If you are not familiar with Lead Time, the Accelerate book defines Lead Time as:

“the time it takes to go from code committed to code successfully running in production.”

and states that:

“shorter product delivery lead times are better since they enable faster feedback on what we are building and allow us to course correct more rapidly.”

That is the first reason to move to CICD​: to speed up our feedback loop​ and gain confidence, through quick iteration and experimentation, that we are in fact building the right thing​.

Reducing the cost and risk of release​

The cost

The problem with our current weekly deployments is that the cadence incurs very significant cost. I have previously written on my personal blog about the cost of slow lead times. On a team of 10 engineers, the costs associated with a one week lead time could be the approximate equivalent of more than 3 engineers, or $400,000 per year. That is a huge cost.

By decreasing the time it takes us to generate revenue from our new features, reducing the costs of necessary work such as coordinating and manual releases, and by reducing work in progress and context switching, we expect to significantly reduce our cost to release.

The risk

The bigger a release, the more changes being released at once​. That means there are more chances of something failing​, and when something does fail, it’s harder it is to know which change caused the problem and so it tales longer to triage the problem.

​With CICD, each release is smaller. When something goes wrong, it is much easier to understand what caused. And of course having a CICD pipeline means you should be able to roll out a fix much faster too.

Creating a better place to work!

The last but by no means least reason for us to move to CICD is for our team.

Right now, some of our releases need to be done outside of working hours (typically after 8pm EST), and require the team to stay late. By moving to a CICD model, we can release anytime, including during working hours, and let the team go home at a reasonable hour. Enabling no-downtime releases is something we can do without moving to full CICD, but it is one of the many improvements that we are doing under the CICD umbrella.

And engineers want to work in a CICD environment. They want to see their changes have an impact quickly. They want to get the feedback of running their code in production. They want to work somewhere where they are working on interesting problems rather than repeatedly running the same manual processes.

Our path to CICD

In the excellent Continuous Delivery book, they talk about some of the practices and principles of continuous delivery, including developing a culture of continuous improvement, building quality in​, automating where you can, and working in small batches​. We are striving for all those things in SageSure, with more work to do in some of the areas than others.

But there are also specific technical challenges we face too. We talked earlier about the need to enable anytime deployments that do not impact customers. For us, this specifically includes migrating to CloudFront for our frontend services, and migrating to Kubernetes (from Rancher) for our backend services. Our Director of Engineering, Chris Lunsford, recently wrote about our Static-Site Architecture here.

We also need an increased focus on our tests. In a CICD world, a passing build should signal readiness for production. In addition to using automated test suites, we have also allowed our release candidates to “bake” in a stage environment, allowing internal users, tests and services to interact and (hopefully) smoke out any issues with a release. This can be an expensive and time consuming approach and we want to be faster and more consistent. Going forward, we want better automated test coverage and less manual. We need comprehensive unit, integration tests and browser based tests. We also in particular need to step up our API tests e.g., using Postman.

And with good test coverage in place, we need to make sure that we are running all the tests we can in production, for post deployment validation.

Finally, after deployment, we need better monitoring, observability and alerting. What does success of a new feature look like and are there specific metrics we can monitor for? Can we automatically detect unhealthy for a new feature, and automatically rollback? Can we optimize for Mean Time To Recover?

All of these are challenging tasks, but we are already making incremental improvements, and we don’t need to solve them all before moving to CICD. While better test coverage is a good way to reduce risk with CICD, more frequent releases themselves also reduce risk. Baby steps. Improve. Iterate.

How will we know if we’re succeeding?​

One of the books we love at SageSure is Accelerate. We covered it in one of our bookclubs and we refer to it frequently. One of the reasons we like the book so much is that it brought a huge amount of data, rigor & scientific analysis to the table​. The authors found a way to define & measure the performance​ of software teams, using these 4 metrics:

Throughput metrics​

• Lead time ​
• Release Frequency​

Stability metrics:​

• Time to restore service​ (aka MTTR)
• Change Failure rate​

As well as finding a way to measure performance, they found a way to predict it. Specifically, they found that the practices of Continuous Delivery predict the high performance of software teams. And what’s more, they found that high performers have practices & principles that allow them to achieve both higher throughput and stability.​

For us in SageSure engineering, these are the metrics we are using as a guide in our migration to CICD.

We think about the the throughput metrics a lot and aiming for smaller batch sizes in the form of lower lead time and high release frequency.

And it is the stability metrics that we use as our guard rails along the way. If move to CICD, and we see an increase in our change failure rate, we are doing something wrong​. And for each failed release, if it is taking longer to restore than what we are currently doing, we are again doing something wrong​. In either case, we would need to step back and take stock.​ ​ Gathering these metrics in advance has been very useful, and going into this transformation, we know​:

• Where we’re starting from in terms of deploy frequency and lead times​
• Where we want to go to: commit to production in an hour​
• The metrics that show us if we’re breaking too many things along the way​ (MTTR and Change Failure rate​)

​So, to answer our initial question, how will we know if we’re succeeding with CICD? We will know when our metrics tell us. When we have improved throughput metrics​ in terms of lower lead time ​ and increased release frequency​, while not negatively impacting our stability metrics. Indeed it would be great to see our time to restore service​ (MTTR) and change Failure rate​ actually improve.

But more importantly, we will also see more and faster experimentation and iteration on features that our customers actually want and use.

Timelines

We are already making good progress and expect to have our first service on a CICD model in a few weeks, with the aim to have a significant number of services and UI apps on CICD by year end.

Will we migrate all projects to CICD? We haven’t decided yet. Instead, we plan to role out incrementally, review the benefits (and costs) and decide then.

We will be sure to create another post detailing or successes and failings as soon as we have meaningful progress to report.

In the meantime, if you are interested in joining us on our journey, please check out our openings and don’t hesitate to reach out.

In the world of blogging, the first thing you write is a post detailing the technology that powers your blog—then you never post again 😆.

In the spirit of keeping with tradition, let’s take a look at what powers this website.

The tech

For this site, we took a JAMStack approach: markdown, templates, and data go through a static site generator and end up as static files deployed to a URL.

The site is entirely under version control. Post authors, site developers, and other contributors all use a Git-based workflow (like many other projects at SageSure). On push, our Gitlab instance has CI/CD to run a build and deploy the site to an s3 bucket. Changes pushed to main go straight to prod, while preview deploys are created at unique URLs for each branch.

Now, to answer the question everyone is asking: what static site generator are you using? We decided to give Astro a shot. It’s the new kid on the block that merges a variety of ideas and approaches pioneered by the other popular static site generators and front-end frameworks.

What’s compelling about Astro is that it takes an approach of “no JavaScript shipped to the client” by default. In a way, it’s all the benefits of a modern front-end developer experience without passing on a lot of the cost of that experience to the client.

Astro: first impressions

It’s worth noting that, at the time of this writing, Astro is still very much in the early stages—not yet to v1. And with their own custom file format (.astro) we’re still waiting for prettier support to get the ever-so-nice “format on save” functionality.

However, as I found, they do have a discord with friendly folks providing the most up-to-date info you could want. It’s a wholesome Github and Discord community—an incredibly valuable asset for a young project with lots of kinks yet to be ironed out.

For me personally, my experience with Astro thus far pretty closely mirrors what Robin Rendle described in his post detailing his attempt to switch from Eleventy to Astro. First, things are changing beneath your feet:

A ton of breaking changes had been made since I updated the version of Astro I was on.

And I only started this project a few weeks ago!

Through the course of building this website alone, I went from astro@0.16 to astro@0.20. Fortunately, I wasn’t doing anything sophisticated enough to merit breakage (at least that I know of 😬). In fact, bumping versions actually fixed a few minor bugs I’d noticed and meant to investigate but the Astro folks got to them first fortunately!

With that in mind, set your expectations accordingly! If you’re mad about APIs shifting under your feet, you probably shouldn’t be building anything on software versioned at 0.x.x. However, to be sympathetic, it’s one thing to know things are going to be changing and set your expectations accordingly, and it’s quite another to actually experience the frustration of it and realize “maybe I wasn’t as prepared for this as I thought!”

Astro: glass half full perspective

Chris Coyier writes about why he’s bullish on Astro, boiling it down to two major advantages:

1. The JAMstack approach (static HTML/CSS/JS with a no-JS by default approach)
2. Componentization

Regardless of its status as beta software, both of these advantages shine in Astro right out of the gate. As Chris stated, Astro has a vibe of “we’re gonna steal every last good idea we can from what came before, and lean on what the native web does best”.

If you’re worried about adopting something so earlier, don’t. Basic static use cases like a blog could be ported to another static site generator without too much hassle—its merely templates, markdown files, and static assets.

One last thing…

Don’t miss our RSS feed for this blog—why would you read a blog any other way?