
Many teams start by building a monolith because it helps them move quickly when they need to get something to market. As organizations grow and the product becomes more complex, it becomes more difficult to maintain and innovate on a monolithic application. But it’s also challenging to know how to break up a monolithic application into microservices: to decide it’s time to make the investment, to determine how to approach it, and to balance that work with more direct revenue needs.

We’ve seen that some of the key business triggers for evaluating this transformation to microservices come when:

- Products move up-market and need to reach enterprise customers
- Innovative features can’t be built quickly enough
- A particular component of the product has different scale and performance requirements
- The org is trying to attract and retain top tech talent
- Cloud migration creates an opportunity for app modernization

In this post, we’ll take a look at the decision-making process for when to invest in breaking down the monolith using microservices and share our advice on how to get started.

## Monolithic architecture vs microservices

Let’s start with some definitions.

A [microservice](https://martinfowler.com/articles/microservices.html) is an independent service that is built to model a business domain. Using microservices is therefore structuring your application to be built with a suite of microservices that collectively encapsulate all the [business capabilities](https://thenewstack.io/microservices-vs-monoliths-an-operational-comparison/).  Each microservice has completely independent building, testing, and releasing. This means the only coupling between services should be the exposed interface. There is minimal central orchestration and the [communication](https://articles.microservices.com/monolithic-vs-microservices-architecture-5c4848858f59) is typically done using Messages (Topics or Queues), HTTP/REST or RPC.

Alternatively, we have the [monolithic application](http://microservices.io/patterns/monolithic.html) which is an application that is built as a single unit. Building a monolith is [more natural](https://articles.microservices.com/monolithic-vs-microservices-architecture-5c4848858f59), where all the request handling logic runs on a single process. However, it makes it harder to keep the code modular and decoupled, and risks small changes having adverse effects on downstream dependencies. Modifications also require the whole monolith to be rebuilt and deployed. Monoliths can scale by replicating the entire application onto another server and having a load balancer distribute incoming requests. Conversely, microservices can scale by replicating only the services that are needed.

![Microservices.png](img/blog/breaking-down-your-monolith/microservices.png)

## Pros and cons of microservices and monoliths

The annoyances that monoliths cause have led to microservices being highly desirable, but it’s still important to not be idealistic about what they provide. When thinking about a monolithic architecture vs. microservices, it’s helpful to consider the tradeoffs you make with each. Microservices are trading runtime complexity for build time simplicity and runtime scaling. Monoliths have build complexities and runtime simplicity, but typically higher scaling costs.

Let’s look at both sides.

### The Microservice

Each microservice is independently deployable and scalable, as there is a clear boundary between each of the services. Loose coupling means that in-service changes only require the individual service to be redeployed.

This also means that if one module in your monolith requires significantly more scale than others, breaking it down can be a good way to optimize compute and memory costs because you’ll allow the module to scale independently.

On the flip side, the fundamentally decoupled nature of microservices means that remote calls must be made. Compared with in-process calls, the overhead of remote calls is significant. This means that communication interfaces can’t feasibly expose efficient functionality for fine-grained control. Instead, the approach must be replaced with coarser-grained interfaces to reduce the number of network calls. There is more overhead for developers handling each microservice’s individual deployment and management, which is sometimes referred to as the ‘microservice tax’. This tax is often only a fair [trade-off](https://martinfowler.com/articles/microservice-trade-offs.html) in large complex environments. If you can manage the system complexity as a monolith, then the cost may not be worth it.

### The Monolith

Monoliths tend to be considered synonymous with legacy, and thus there is the line of thinking that monolith applications are inherently bad. But they do have upsides in some situations. Containing code to one application means that you can just use it, instead of deciding how to share your code in a distributed system. They’re easy to reason about and usually easy to test locally since they’re just a single app to run.  

However, some dev complexity is much greater in monoliths. Upgrading dependencies, for example, can be nearly impossible in complex systems where a dependency is used extensively and a new version contains breaking changes. Also, someone else’s changes can impact the performance or security of your module, so monoliths tend to make the trivial parts of debugging easier, but make the hard stuff really hard.

Overall, microservices are less complex than most people make out, and monoliths aren’t really much simpler. Our assessment: if automated testing and deployments aren’t your team’s strong point or priority (for example, if you have a smaller team and a quarterly deployment schedule), monoliths are a perfect choice. However, if you need regular granular releases and your team is investing in highly automated testing and deployment, you’ll typically be more successful with microservices.

## When to start breaking down your monolith

If microservices are the right path for you, then the best time to switch is when the application meets the trade-off intersection between monoliths and microservices. This is generally where your application has become large, complex, and is supporting numerous different business capabilities. That way, each capability’s boundaries can be identified and then separated into a distinct microservice. Before decomposing into microservices, the monolith should be approaching a point where the high cost and slow pace of change make it ineffective and inefficient for new features or modifications. 

As mentioned earlier, this often happens when a business needs to innovate, scale features, and meet customer requirements. While these are compelling needs, the process is still a big investment that causes teams to pause and try to push back this work. Here’s our advice for breaking down the work of breaking down the monolith 😄 so that it isn’t quite as daunting and hard to connect to business value.

## How to break monolithic applications into microservices

It doesn’t have to be a massive journey to transition to microservices; there are many ways to minimize your risk and effort. The key is to make **incremental changes**. 

An incremental approach to decomposing the monolith into microservices gives you the chance to learn about microservices while also minimising the impact they have on the production system. This means that business operations and revenue growth can still be prioritised during the refactoring.

The benefits of an incremental approach make it extremely practical. You gain feedback on each microservice, rather than finishing a ‘big-bang’ approach and realising it didn’t meet any of your goals. This feedback provides an opportunity to stop at any time. If you create a few microservices that achieve the goal set you can just stop there. It is perfectly valid to have a hybrid architecture with a monolith that has supporting microservices.

Here are a few tips for how to get started and approach breaking down your monolith incrementally. 

### Pick the first microservice to extract

The easiest way to start is to start small–identify a single module that you’ll extract from the monolith. Ideally, the first choice should already be heavily decoupled from the monolith, doesn’t require many changes to client-facing applications, and doesn’t interact with a data store. With these factors, the risk is low, as any downstream dependencies are unlikely to break. 

Before picking which microservice to start with, remind yourself that microservices aren’t the goal. Microservices serve to achieve your goal, and you’ll want to have a clear understanding of what that is, so you don’t get caught up in attributing activity with results. Your clear goal will inform what microservice you should build first, so you start with something that will give you the most value immediately. 

A final piece of advice about which microservice to start with: this first microservice is going to require new CI/CD pipelining, development tooling, testing, monitoring, logging, and securing, most of which won’t be the same as it was in the monolith. Hence, for laying this groundwork it’s a good idea to start with a simple service. It also allows the team to focus on learning and up-skilling.

### Build new modules as microservices

Likely even easier than extracting an initial microservice from your monolith, start instead by building an entirely new feature from scratch. You might have a feature that’s been on your mind for a while but you’ve put it off because of the overhead it might add to your architecture. This approach gives you the benefit of focusing your development on adding new value to the product, while also allowing you to leave the existing monolith intact. 

### Try the strangler fig pattern

One useful pattern for employing incremental change is the [strangler fig pattern](https://martinfowler.com/bliki/StranglerFigApplication.html). It is an incremental approach where a system grows over an old system until the old system is ‘strangled’ and can be removed. The slow incremental change means that each step can be monitored over time; making the probability of something breaking quite low. Shopify has a [good walkthrough](https://shopify.engineering/refactoring-legacy-code-strangler-fig-pattern) of how they refactored their core system using this method.

### Rely on other tools

Using tools means you can focus on your business-level application code, and stop attempting to reinvent the wheel. Tooling is built with industry best practices in mind, so you don’t have to do the research yourself. Microservices have been ramping up in popularity for a while now, and the ecosystem has reflected this. There are hundreds of tools all tackling different problems, including messaging, logging, orchestration, deployment, and more.

For example, managed services have implemented the backend for frontend pattern with the use of API gateways. API gateways act as the entry point of service requests, taking care of proxying or fanning out requests to one or more services. The Nitric framework supplies painless tooling for creating [API gateways](https://nitric.io/docs/apis) and other commonly used resources like events, queues, and collections.

To stay most productive with your monolith decomposition, leverage tools to take away those additional burdens.

### Decouple data strategically

If multiple applications are reading and writing to a central data store it can be a massive blocker to decouple the data as you start decomposing the monolith. It’s important to do it sooner rather than later, as teams can only move as fast as the slowest part. The actual process of decoupling this data depends on how stateless your data is or whether it has a tight coupling to the data store. 

The delivery team needs to use a migration strategy to incrementally migrate and remove the old service’s readers/writers into the new decoupled data store. Stripe details a [migration strategy](https://robertheaton.com/2015/08/31/migrating-bajillions-of-database-records-at-stripe/) that would generally work for most environments that require incremental migration of coupled applications away from production data stores. Using this method or something similar, you can approach the migration with incremental change just like the rest of the monolith decoupling.

## Final thoughts

As we talk to folks taking a look at the [Nitric framework](https://nitric.io), we commonly hear that breaking down their monolith is a challenge. Hopefully, these ideas give you a good starting point for approaching your monolith decomposition and app modernization with incremental changes. And of course, using the Nitric framework can help by removing the burden of deployment and infrastructure.

We’d love to hear which of these tips you try out. How do they work for you? Would you be interested in a guide on how to structure your Nitric project based on monolith vs microservice patterns? 

Reach out on [GitHub](https://github.com/nitrictech/nitric/discussions) and [Twitter](https://twitter.com/nitric_io) to start the conversation!

Monolithic applications provide dev challenges over time. Evaluate when to invest in breaking down the monolith into microservices and how to approach it.

Breaking Monolithic Applications into Microservices


We're excited to announce that we've hit over 300 stars on our core github repo and have just been accepted into the [CNCF serverless landscape](https://landscape.cncf.io/serverless?selected=nitric)!

A huge thanks to to everyone who has shown their support by giving us a star.

We're very excited to continue building the Nitric community and to keep growing the framework, making it easier then ever to deploy to the clouds of your choice all from a single codebase.

If you're new to nitric and want to start building cloud applications check out our [getting started guide](/docs/getting-started)


Nitric reaches 300 stars and qualifies for CNCF landscape listing

Nitric listed in CNCF serverless landscape


Recently we relaunched our website and Node.js SDK for [nitric](https://nitric.io). These are the lessons learnt and reasons we chose to relaunch our SDK.

## The original approach

Initially, the nitric framework used a `nitric.yaml` file, allowing users to define
their application's infrastructure separate from their code.

Developers would reference the resources in their nitric.yaml file by name in their application code.

## Dogfooding our own tech

<img src="/img/blog/config-as-code/dog-bowl-flip.gif" alt="video of a dog flipping a food bowl" />

The initial design was a huge improvement on what we'd used to build cloud-native apps in the past. The tech was ready to go, so it was time to build with it and enjoy how much easier our hard work was going to make the future of application development.

Our new project started with a CRUD API, simple enough right? Write some basic HTTP handlers,
wire in some resources like buckets and collections, then define the API with a standard approach like OpenAPI. Easy... or so we thought.

### Wiring up resources

As stated above, every project included a `nitric.yaml` file describing how a nitric project was to be deployed. The file included names for resources and the handlers for serverless functions:

```yaml
name: my-project-name

functions:
  example-function:
    handler: functions/example.ts

collections:
  example-collection: {}

queues:
  example-queue: {}

buckets:
  example-bucket: {}

topics:
  example-topic: {}

api:
  example-api: {}
```

The resources could then be referenced in code, using their name and our SDKs:

```typescript
import { faas, storage, eventing, collections, queues } from '@nitric/sdk';

const topic = eventing().topic('example-topic');
const collection = collections().collection('example-collection');
const queues = queues().queue('example-queue');
const bucket = storage().bucket('example-bucket');

faas.http(async (ctx) => {
  // your logic here
});
```

Without going into a full example, this approach lead to a few pain points:

- It was error prone, especially to typos
- Refactoring resources was challenging
- Definitions were always duplicated, in the yaml and again in the code

Additionally, we also had to define our APIs using OpenAPI specs.

### Defining the API

The project started out defining a simple CRUD API with a few models to handle, not massive but not small either.

Functions in our application would be wired via an API gateway, defined in the spec using an operation level OpenAPI extension like so:

```yaml
x-nitric-target:
  name: my-function
  type: function
```

The problem with these specs was that OpenAPI is quite verbose, even for simple schenarios. So, **_700 lines_** of API spec later, we'd had enough! It was starting to become unwieldy and prone to errors for simple changes and just plain hard to look at.

This isn't a criticsm of OpenAPI, but of our approach. There are generally two schools of thought when it comes to building out contract driven APIs and that is you either:

- write specs first and generate code from the spec; or
- write code first and generate your spec from the code.

Our approach was the worst of both. Hand written specs, wired to hand written functions, without assistive generation for the server-side code in-between.

> The irony of this realisation is [our core tech uses gRPC](/blog/why-nitric-chose-grpc) which exemplifies the first of the above approaches...

This realizaton lead us down the path of revisting the approach, ultimately revamping the nitric framework in the process.

## A new approach, enter configuration as code

We decided to bring our configuration _into_ our code, removing the issues caused by their separation. This is not in the same way that many CDK solutions work today, where application and infrastructure are both written in code but remain seperate.

Instead, we wanted a framework that allows developers to expressively communicate the cloud infrastructure requirements of their application using common cloud concepts like topics, queues, storage etc.

It started from the idea that developers could simply declare and use cloud resources, directly within their applications:

```typescript
import { topic, api, collection } from '@nitric/sdk';

const exampleApi = api('example');
const exampleBucket = bucket('example').for('writing');
const exampleTopic = topic('example').for('publishing');

exampleApi.post('/example', async ({ res }) => {
  // your logic here...
});
```

It was immediately obvious this approach addressed most of the developer experience concerns we had with the original:

- resources are defined in a single location
- refactoring can be done with existing tools and IDEs
- resources can be shared across functions using existing module and dependency systems

As an added bonus, we were now able to declare resources with _intent_ allowing us to implement least-priveledge security practices, something that was proving to be a challenge with our first approach.

## Comparing it with our previous approach

Prior to the implementation of our configuration as code we would need to define:

- A `nitric.yaml` file, containing:
  - function defintions for the application, and
  - API definitions that pointed to OAI3 specs
- An OAI3 `api.yaml` file that defined the API and pointed at the functions defined in our `nitric.yaml`
- The code that defined the functions

This doesn't sound like much, but you can see from this "Hello World" example it can be a lot, even for a basic use case:

**nitric.yaml**

```yaml
functions:
  hello: functions/hello.ts

apis:
  hello: api.yaml
```

**api.yaml**

```yaml
openapi: '3.0.0'

info:
  title: Hello World
  version: '1.0'

paths:
  /hello:
    get:
      summary: Say hello
      description: An endpoint that generates greetings.
      operationId: hello
      responses:
        200:
          description: greeting response
      x-nitric-target:
        type: function
        name: hello
```

**functions/hello.ts**

```typescript
import { faas } from '@nitric/sdk';

faas
  .http(() => {
    return `hello world`;
  })
  .start();
```

> 24 lines just for Hello World, in a non-trivial app your spec alone would more likely be 1000+ lines

### The same example with config as code

**nitric.yaml**

```yaml
handlers:
  - functions/*.ts
```

**functions/hello.ts**

```typescript
import { api } from '@nitric/sdk';

const mainApi = api('main');

mainApi.get('/hello', (ctx) => {
  ctx.res.body = 'Hello World';
});
```

> Thats it! The same app, in just 7 lines.

The team found, with non-trivial applications, this approach also scales better than the previous style.

## How it works

At first glance this might look like a language parsing problem where software would be needed to read the users code to figure out the resources they were actually using, but nitric is a bit different in its approach to abstracting the cloud and we used this to our advantage.

[**The nitric server**](https://github.com/nitrictech/nitric)

When running in the cloud, each nitric function has a lightweight proxy in front of it that abstracts away the implementation concerns of the cloud that its running on. This server can be anything that conforms to the gRPC API spec, so we built a new `resources` API and embedded a "deploy-time" server into our CLI.

Here is what we ended up with (using our AWS provider as an example):

<img alt="example deployment diagram" src="/img/blog/config-as-code/config-as-code.png" />

> This applies to all the clouds and resources we support today

Our latest Node.js SDK and nitric server are built on this approach and we're looking forward to broadening our language support as our community grows and requests come in.

## Give it a try

See for yourself as well, try [building something with nitric](/docs/installation).


How we revamped our framework to cut down on tedious configuration

Using actual code for IaC


Nitric’s core value is language-agnostic abstraction from cloud infrastructure. We accomplish this with a set of easy to learn, consistent APIs including storage, documents, events, queues, and more.

The question for us was what technology to use to communicate between applications and the Nitric service that provides those decoupled APIs.

![nitric technology flow diagram](/img/blog/why-nitric-chose-grpc/membrane-diagram.png)

_(Check out our core github repo for more info on how the nitric membrane works)_

Ideally, this technology would:

1. Minimize overhead
2. Be strongly contract-driven
3. Provide tooling for client/server generation
4. Have awesome community support

### Enter gRPC

Open-sourced in 2016 by Google, gRPC is quickly growing in popularity as a tool to build APIs, especially for [microservices](/blog/break-monolithic-application-microservices), container sidecars and service-to-service communication.

Preliminary research into gRPC revealed several advantages over familar REST/HTTP based alternatives, such as OpenAPI (Swagger). We began our foray into gRPC by creating a simple abstraction that would allow developers to read contents from blob storage both locally and across clouds.

```protobuf
syntax=”proto3”;

service Storage {
  rpc Read(ReadRequest) returns (ReadResponse);
}

message ReadRequest {
  string bucket = 1;
  string key = 2;
}

message ReadResponse {
  bytes content = 1;
}
```

> From memory it looked something like this, definitely should have streamed the response, but we were still learning 😅

That was it, we generated a simple server in Go (more on our choice of GoLang in a later blog) and started testing using [BloomRPC](https://github.com/bloomrpc/bloomrpc) _(it's kind of like Postman for gRPC)_, once we had pluggable working implementations across clouds (GCP and AWS at the time) we were hooked!

From there it grew, first generating basic clients for various languages (Node.js and Python), adding more methods and service types, and eventually writing idiomatic wrappers for improved developer experience over the auto generated clients.

There were some teething issues we had to work through (the default python code gen being one - btw, huge shoutout to the team working on [betterproto](https://github.com/danielgtaylor/python-betterproto), it's awesome!). But all in all, from our first contact with gRPC, we could easily see how it checked all the boxes for what we needed.

### Fast & Efficient

gRPC brings together the efficient connection management of HTTP/2 with the compactness of [Protocol Buffers](https://developers.google.com/protocol-buffers) for data serialization. This greatly reduces overhead when compared to HTTP/1.1 and traditional text based serialization such as JSON.

#### HTTP/2 vs HTTP/1.1

gRPC lets us take advantage of significant performance improvements made to HTTP/2 over HTTP/1, specifically with connection reuse and streaming. HTTP2 can send multiple requests/responses using a single connection where HTTP1 must re-establish a new TCP connection per request/response, reducing connection brokering between two systems improves overall latency and overhead.

I won’t rehash performance comparisons between the two, since many already exist, instead I'd recommend taking a look at this article from [DigitalOcean](https://www.digitalocean.com/community/tutorials/http-1-1-vs-http-2-what-s-the-difference) and another from [css-tricks](https://css-tricks.com/http2-real-world-performance-test-analysis/) for a detailed breakdown on performance.

#### Protocol Buffers v. JSON

Moving data over the wire takes time, the larger the payloads the more time they take. This is where Protocol Buffers shine over traditional text based serialization such as JSON.

Consider a simple payload represented in JSON:

```json
{
  "name": "Tim"
}
```

In Protocol buffers we could define the message as:

```protobuf
message Person {
  string name = 1;
}
```

Translating the above to an on onwire translation gives this result:

`0x0a 0x03 [0x54 0x69 0x6d]` (brackets here encapsulate the payload).

> Note: checkout Google's developer docs to see a detailed explanation of [encoding in gRPC](https://developers.google.com/protocol-buffers/docs/encoding#simple)

If we use the above payload, the 'weight' of each representation on the wire is:

JSON: 14 Bytes

Proto: 5 Bytes

On the wire the proto payload is only _**35.7%**_ the size of the JSON representation!

Also, depending on how your JSON schema is designed, binary serialization will generally scale far better for large payloads without sacrificing the comprehensibility of your contract (e.g. truncating key names to save bytes).

Streaming was also a big factor for Nitric, our [Nitric Server](/docs/concepts#nitric-server) is built on gRPC streams, which we'll be sure to cover in a future blog.

### Clear Cut Contracts

Another strength of gRPC is the DSL used to create contracts. It's clean, readable and easy to document, particularly in contrast to OpenAPI (formerly Swagger) specs.

#### Proto3 vs OAI3

<CodeExamples
languages={[
	{
		label: "Proto3",
		value: "proto3"
	},
	{
		label: "OpenAPI",
		value: "openapi"
	}
	]}
	defaultLang="proto3"
>

<CodeExample lang="proto3">

```protobuf
service User {
  rpc Create(CreateUserRequest) returns (CreateUserResponse);
  rpc Read(ReadUserRequest) returns (ReadUserResponse);
}

message User {
  string id = 1;
  string email = 2;
  string name = 3;
}

message CreateUserRequest {
  User user = 1;
}

message CreateUserResponse {
  String id = 1;
}

message ReadUserRequest {
  string id = 1;
}

message ReadUserResponse {
  User user  = 1;
}
```

</CodeExample>

<CodeExample lang="openapi">

```yaml
openapi: 3.0.0
info:
  version: 1.0.0
  title: User API
  description: User API
paths:
  /user:
    post:
      operationId: user-create
      description: Creates and persists a new user
      responses:
        '200':
          description: Successful response
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/User'
  /user/{id}:
    get:
      operationId: user-get
      parameters:
        - in: path
          name: key
          schema:
            type: string
      description: Retrieve an existing user by its ID
      responses:
        '200':
          description: Successful response

components:
  schemas:
    User:
      type: object
      properties:
        id:
          type: string
        email:
          type: string
        name:
          type: string
```

</CodeExample>

</CodeExamples>

The improvement in readability is pretty staggering. While OpenAPI 3 is extremely flexible and encompasses most capabilities of HTTP, the opinionated nature of proto3 and gRPC gives it an edge when it comes to simplicity, enhancing readability.

Lastly, because Protocol Buffers use indexes over keys for data serialization, detecting potentially breaking changes in contracts is much easier. This is evident in the wide range of tooling that helps facilitate contract validation and linting for proto files such as [Buf](https://github.com/bufbuild/buf). Allowing for breaking change detection as part of CI pipelines can assist in blocking changes that will alter the backwards compatibility of a contract.

### Tooling and community

Despite only being open-source since 2016, the gRPC community has grown rapidly. There's an expanding ecosystem of implementations and code generation for a variety of languages and other communities.

Protoc (the gRPC compiler) and surrounding tooling played a large part in the decision to use gRPC for Nitric. The ability to generate clients which connect to Nitric’s unified APIs from proto contracts was critical to our multi-language support and automating these builds ensures our base SDKs never get left behind when improvements are made.

In our current CI/CD pipelines we automatically produce base client libraries for the Nitric API on every publish of the core framework.

![Github actions pipeline](/img/blog/why-nitric-chose-grpc/github-action-pipeline.jpeg)

You can see how we built this automation in our GitHub repos using GitHub Actions workflows. https://github.com/nitrictech/nitric, https://github.com/nitrictech/apis

To see how we consume these auto-generated API clients and wrap them into more language idiomatic SDKs, check out our SDK projects for our supported languages:

- https://github.com/nitrictech/node-sdk
- https://github.com/nitrictech/python-sdk
- https://github.com/nitrictech/java-sdk
- https://github.com/nitrictech/go-sdk

### Conclusion

This isn't an argument that gRPC is a silver bullet for all things API. When it comes to building and designing services, there is no one size fits all and needs/constraints will differ from project to project. If you have a project with similar requirements to Nitric, or simply want to create a language-agnostic programmatic wrapper for a set of tooling, then I would highly recommend trying a PoC with gRPC. Getting started is easy just check out the [docs](https://grpc.io/). You could even use Nitric as inspiration; our core and unified APIs are fully [open source](https://github.com/nitrictech)!


Choosing gRPC for Cloud and Microservice APIs


Microsoft just announced their general purpose managed container platform [Azure Container Apps](https://techcommunity.microsoft.com/t5/apps-on-azure/introducing-azure-container-apps-a-serverless-container-service/ba-p/2867265).

Container Apps provide a convenient way for developers to deploy containerized applications into a flexible serverless environment that provides easy to configure horizontal scaling without the burden of building or managing your own kubernetes clusters.

We're excited to say, just two days later, we've added support for deploying [Nitric Compute](/docs/reference) resources, including Serverless Functions & Containers to Azure Container Apps. Our initial preview of Azure support, released last Friday, deployed Compute assets to Azure App Service, but Container Apps provides many advantages including better support for non-public containers, a new event driven autoscaler and scale-to-zero.

Install the latest RC Release of our [Azure CLI plugin](/docs/reference/azure#usage) and [configure your azure subscription](https://docs.microsoft.com/en-gb/azure/container-apps/get-started?ocid=AID3042118&tabs=bash) to try it out for yourself and start using Container Apps in just a few minutes.

If you're new to nitric and want to start building cloud applications check out our [getting start guide](/docs/getting-started)


Nitric now supports Azure container apps for deploying compute resources

Azure Container Apps with Nitric


The Nitric team is thrilled to announce the latest release of our Preview of the Nitric Framework… it’s a big one!

### Highlights

This release focused heavily on applying the feedback of those using Nitric to improve the developer experience, enhance productivity and make the solution more intuitive for new users.

#### Docs Site

- **New Site Layout** which separates guides, reference docs and samples making it easier to quickly find the information you need
- **Refreshed "Getting Started" Tutorial** to guide new users of Nitric through building their first portable cloud-native application
- **Tested Code Snippets** all code examples on our docs site are now imported directly from GitHub and automatically tested with CI to improve accuracy
- **Enhanced "Concepts" Section**, which explains the core concepts behind Nitric and how to choose the right project structure for your needs

#### Nitric Core & CLI

- **Preview Azure Support!** We've enabled Azure as a deployment target for preview with support for managed services including App Service, Azure Container Registry, Azure API Management, Cosmos DB, Azure Front Door, Azure Event Grid, Azure Storage, Azure Storage Queues & Key Vault
- **Code Sharing** between Functions in the same Nitric Stack via a new Stack structure and build process using Cloud Native Buildpacks
- **Secrets Service** enables you to store your application secrets and credentials backed by AWS Secrets Manager, Google Secret Manager and Azure Key Vault.
- **Enhanced Local Storage Service** through migration to Minio server when running Nitric applications locally, which better replicates cloud service behaviour and enables pre-signed URL support for file upload/download
- **Improved API Definitions** allowing API gateway definitions to be stored in their own OpenAPI 3 spec file and referenced from nitric.yaml
- **Custom Containers** which enable stacks to mix and match Serverless Functions and custom-built Docker containers in the same project
- **Stack Template Validation** to detect and correct issues earlier for local build and deploy
- **Document Results Streaming** allowing document query results to be streamed, providing an alternative to manual pagination
- **Error Code Standardization** of Nitric server error codes to improve DX for API consumers
- **General Enhancements and Bug Fixes** - see our GitHub [release page](https://github.com/nitrictech/nitric/releases/tag/v0.12.0) for details

![code example](/img/blog/nitric-preview-launch/faas-code-example.svg)

#### SDKs (Node/Python/Java/Go)

- **Context API** for Nitric Functions for reading/writing request and response information
- **Composable Middleware** for Nitric Function handlers allowing improved reuse and modularity in function development
- **Fluent Style SDKs** to improve discoverability when working with IDEs
- **General Enhancements and Bug Fixes** - see the release notes of individual SDKs on [GitHub](https://github.com/nitrictech) for details

### Tips for Upgrading

- Your nitric.yaml needs to change, check our new [docs](/docs) for the format differences - primarily around Nitric Functions
- Our new stack template structures provide base scaffolds for our new stack and directory structure. This should help upgrades to the new context APIs and enable code sharing between functions.
- For existing projects, you'll want to upgrade the SDK version you're using to unlock the new features and fixes

### A few more things in the works

We've still got more in the works, here's a preview of what we're working on next. Think we're missing something? Let us know:

- Improvements to Serverless Function build performance
- Pre-signed URL support for Google Cloud Storage

### Learn

We know that building APIs as well as protecting them can be a bit daunting, so check out our easy to follow [getting started page](/docs/getting-started).


Announcing the latest release of the Nitric Developer Preview, with Azure Support

Nitric Blog: Build Serverless Apps Fast

Breaking Monolithic Applications into Microservices

Ryan Cartwright

Engineering

Nitric listed in CNCF serverless landscape

Tim Holm

Co-founder and CTO

Using actual code for IaC

Tim Holm

Co-founder and CTO

Choosing gRPC for Cloud and Microservice APIs

Tim Holm

Co-founder and CTO

Azure Container Apps with Nitric

Tim Holm

Co-founder and CTO

Nitric Preview | October 2021 Release

Jye Cusch

Co-founder and CEO