DEV Community: Erlang Solutions

Code BEAM America [virtual]

Erlang Solutions — Thu, 23 Sep 2021 07:41:37 +0000

Created by developers, Code BEAM America is dedicated to bringing the best minds in the Erlang and Elixir communities together to SHARE. LEARN. INSPIRE.

Over 3 half days you will learn from 50+ cutting-edge talks and our in-depth training program, how BEAM languages are used in production and revolutionising areas like eCommerce, Engineering, IoT, Gaming, Blockchain, Fintech, Security, Machine Learning and more!

As always, community and social interaction will be at the core of the event to enable everyone to connect and interact to share the same experience as with our physical conferences. We offer the opportunity to mingle and meet naturally during coffee breaks and after show virtual party.

FIND OUT MORE https://codesync.global/conferences/code-beam-sf-2021/

Win a ticket to RabbitMQ Summit 2021

Erlang Solutions — Wed, 07 Jul 2021 14:47:19 +0000

We're proud to be bringing together the biggest names in tech to champion RabbitMQ, the most deployed open source message broker in the world. We have a limited number of free tickets to giveaway as guests of Erlang Solutions. If you'd like to join us, alongside speakers, sponsors and attendees from AWS, Github, Bloomberg and many more sign up for your chance here

New webinar: Introducing Caramel - OCaml on the BEAM

Erlang Solutions — Thu, 26 Nov 2020 16:26:04 +0000

New webinar: Hear from the creator of Caramel, Leandro Ostera. He'll demonstrate the benefits of running OCaml on the BEAM, and the ambitious roadmap that allows developers to make the most of Erlang's runtime and error handling alongside OCaml's type-checker. Register at https://www2.erlang-solutions.com/webinar-registration-2

Free Ask Me Anything Session with the speakers of Code Mesh

Erlang Solutions — Fri, 30 Oct 2020 14:17:37 +0000

Hey All,

On Monday 2 November we will be hosting a free Ask Me Anything session with a number of the speakers for Code Mesh. Including Ron Pressler, who is the technical lead for Project Loom, which aims to add delimited continuations, fibers and tail-calls to the JVM.

The event will be hosted by Francesco Cesarini, Found of Erlang Solutions and O’Reilly published author of Designing for Scalability with Erlang/OTP and Erlang Programming

The complete guide to Instant Messaging and in-application chat.

Erlang Solutions — Tue, 13 Oct 2020 16:13:59 +0000

Now more than ever, Instant Messaging is vital to help businesses, teams, and each other, stay connected.

Our MongooseIM team has been building enterprise chat applications for over a decade. To help you and your users stay connected, they've put together everything you need to know about Instant Messaging before building a chat application.

The guide compares the benefits and drawbacks of building your own chat application versus buying a product-as-a-service and looks at what the most desired features of a chat application are.

Read the guide at https://www2.erlang-solutions.com/completeguidetoinstantmessaging3

XMPP #Chat #InstantMessaging #DigitalSolutions

JIT compiler for the BEAM

Erlang Solutions — Tue, 06 Oct 2020 14:46:06 +0000

Last month, our colleague Lukas Larson launched the JIT compiler for the BEAM VM. The JIT compiler offers a performance boost of anything from 30% to 130% increase in the number of iterations per second. In our latest blog, Lukas demonstrates the performance testing of the JIT Read more at https://www2.erlang-solutions.com/jitblog2

New webinar: How Elixir Made Me A Better Java Programmer

Erlang Solutions — Thu, 01 Oct 2020 14:12:20 +0000

We're excited to announce that Juliana Helena will be joining us on the webinar this month.

She'll be expanding on the talk she gave at ElixirConf US early in September. The webinar will focus demonstrate that learning a new, purely functional programming paradigm forces you to examine the way you approach programming. In doing so, it can help you identify habits that can be improved and introduce you to new ways of thinking about problems. This fresh perspective is invaluable for all future development you do, regardless of what language you are working with.

3 Massive Upcoming Virtual Tech Conferences

Erlang Solutions — Wed, 29 Jul 2020 15:46:38 +0000

Hey team,

We're onboard to help out with three of our favourite conferences who have now gone virtual.

Code BEAM V

10-11 of September. This is the speaking line up that was originally organised for Code BEAM STO, now delivered online. Speakers include Viktória Fördős (Cisco NSO Core), Christopher Price (Ericsson Head of Software Technology), Robert Virding (Co-Creator of Erlang & Erlang Solutions, Senior Systems Architect) just to name a few. Early Bird tickets are available but closing soon. See the full speaking line up and buy tickets here.

ElixirConf EU Virtual

7-8 October. Our first ElixirConf EU Virtual in June had over 400 attendees, and the feedback was overwhelmingly positive. The second edition of ElixirConf EU Virtual will feature the same brilliant line-up of speakers that we had organised for this year’s physical event - only virtually. We’ve organised one of the most exciting events we’ve ever had with talks from Chris McCord, Linda Achieng' Otieno, Sigu Magwa, Marlus Saraiva and heaps more. See the full speaking line up and buy tickets here.

Code MESH V

Code Mesh is London’s leading alternative tech conference, designed to be a melting pot for curious, inquisitive innovators. The conference connects programmers who believe in finding best-of-class solutions to any problem. Going virtual means their cross-language community goes global, allowing Code Mesh V to connect and inspire even more people. Very Early Bird tickets sell out within 24h every year, but you can join the waiting list here.

If you’d like to be part of the first ever global Code Mesh V event and inspire the cross-language community of ambitious programmers the call-for-talks and call-for-tutorials are now open.

Lessons learned from a decade consulting XMPP clients

Erlang Solutions — Fri, 26 Jun 2020 14:00:27 +0000

Over the last ten years, we have helped A LOT of companies add value to their products using MongooseIM or XMPP based chat applications. This has allowed us to partner with, and get insights from companies spanning almost every industry and company size. You may wonder how much variety and complexity a team who specialises in scalable Instant Messaging is exposed to, but the truth is, the only thing that ties these projects together is MongooseIM, our scalable, customisable XMPP server. Once we dive deeper into the needs of our clients, we usually find deployments need new features, tailored to their specific need, to help them achieve their most critical business objectives.

Customisation is what sets the work we do apart. We make sure that your Instant Messaging is fit for purpose. Even when XMPP or MongooseIM offer a rich enough chat experience, there are other details we mare are right to deliver a reliable solution. This includes taking into consideration your workload and usage scenarios to ensure that you have the scalability to guarantee uptime.

How can we create or improve a chat experience for your business and its customers?

Building and maintaining a chat application is a continuous process. We join our customers at many different stages, and depending on their needs, we can help in different ways. Let's take a closer look at some examples.

Building a bespoke solution.

We can become an embedded part of the team that builds the service. This allows us to architect and build the solution together from scratch. From the very first day, we learn about the unique properties of the customer and how instant messaging helps them to achieve their goals. As a result, we can use our expertise to make sure the system is built perfectly, from the start, before any less-than-ideal decisions are made. An added benefit of this for our customers is that their team gets to see how we go about architecting and designing a best-practice system. That way, there is a natural knowledge sharing of every step in the process, so when the product is launched and in-use, your team is familiar with how to operate and maintain your system. When possible, this is the perfect option for both the organisations we work with and us.

Improving and optimising before release.

We can't always be there from the start. Sometimes, there is a proof of concept application ready which needs improving, often because there is a technical issue that needs to be solved before the release.
At this stage, it's still possible to help design the architecture of the entire chat system. We can also deploy it to the production environment and make sure it can cope with the increasing load introduced by new users. There are a number of common problems we help solve for companies looking to optimise their chat before release.

One of the most common reasons companies need help at this stage is that developers who have less experience with XMPP have implemented inadequate solutions which have already been solved by the existing, public XEP - XMPP extension.

We also often see problems arising when a custom extension is built on top of an existing one, which, when done incorrectly, can cause significant complications.
In the lead up to the release of a chat solution companies often need help with custom integrations.

This is especially true for companies adding real time chat to an existing product. In many cases, this can be done outside of the MongooseIM code, on the other hand, it's usually more scalable and efficient if it can be run within MongooseIM. Not every company has the need to hire full-time Erlang developers, especially for implementing a few integrations. Our team are experienced, ready and happy to help with custom integrations to ensure the reliability and scalability of the release.

To ensure success when working with an existing product that has yet to be released, we often need to take a step back and look at the product, its goals and its failures holistically. From there we can suggest the best solution. This may mean we need to rethink the existing implementation and change or reshuffle some of the code. In extreme cases, we may need to throw away large chunks of the existing solution to ensure the release is successful. This is the last resort and a decision that is taken collaboratively in the name of reaching an optimal solution.

Increasing the scalability of your chat to allow you to handle more users.

Your instant messaging is deployed and running. Your product is growing successfully. It should be a time to celebrate, but often increased adoption or use of a chat application comes with increased scalability issues. These need to be sorted fast and future-proofed to avoid giving your users a poor experience and damaging the growth you've worked hard to achieve.

Our role is to find the bottlenecks and fix them. We study the architecture, the server setup, configuration, enabled extensions and customised code. Then, we decide on the best possible solution together, in collaboration with our clients.

Improving or customising your chat application.

All right, the app is deployed, and users are chatting, so far so good. How can joining forces with us make things even better? There are many reasons companies will come to us to improve an existing instant messaging solution.

Many of our customers come to us to develop unique functionalities that are necessary for their success. We help by designing the extension on the protocol level and implementing it on the server.
The public XEPs only cover use cases which are generic and where other people deploying chat services based on XMPP can also use them. So, if your chat needs a specific functionality, we're always happy to help.

We also have projects where MongooseIM replaces another XMPP server. This is common when clients discover that the MongooseIM alternative technology they have chosen did not meet their expectations. A common reason for this is that out of the box functionalities can turn out to be black boxes that make it impossible to carry out necessary customisations or improvements.

Another common reason to switch to MongooseIM is to improve scalability when an existing solution reaches its capacity. In this case, we play the role of surgeons, carefully implementing a transplant to put MongooseIM at the heart, improving scalability but keeping the rest of the system running smoothly.

Tips to avoid common mistakes when using open-source MongooseIM:

Choose your XEP, and choose wisely.

X in XMPP stands for eXtensible. This means it might not be the simplest protocol, but there's hardly a chat feature it doesn't cover. There is a set of core RFCs on top of which custom extensions (XEPs) are built. There are usually no issues with the core functionality that is covered in RFCs. They are adopted by many client libraries and servers. XEPs are often isolated from each other, independent from the core functionalities. They add extra features or capabilities to the core of XMPP. Here comes the biggest challenge: deciding which XEP to choose (you can find more details in our XMPP use-cases guide). From our experience, developers starting their adventure with XMPP may have a hard time finding a suitable XEP. This can sometimes accidentally lead to your choice creating difficulties or limitations. Some examples:

Too many extensions are enabled on the server-side, but not used by the client app.

Certain XEPs like XEP-0012: Last Activity put extra load on the server, even when the client's application is not using them. Enabling only used extensions helps to scale the MongooseIM cluster.

An outdated or rejected extension is used.

Often, different products with instant messaging functionality store the messages on the server. For this, there is extension XEP-0313: Message Archive Management. The majority of servers and client libraries have implemented the XEP for several years already. It replaces an old, more complicated and now deprecated XEP-0136: Message Archiving. Sometimes, developers choose the deprecated extension over the new one.

A custom extension is built even if an existing XEP covers the required functionality.

For instance, if a user wants to know if someone is active in a chat conversation. To achieve that, some extra XMPP stanzas need to be sent. Developers, me included, are creative creatures, and sometimes we rush to reinvent the wheel. In this particular case, XEP-0085: Chat State Notifications fulfils this need.

Reduce unknowns

When preparing for a wave of users using instant messaging functionality, we need to remember to load test. It's very crucial to run load tests to know the capacity of your production setup. To my surprise, this is often neglected. Many people want an answer to the following simple question: "how many resources do I need to handle X number of users, sending Y messages per second". There are too many factors and variables to accurately answer this question. To have a better idea about the capacity, you can run load tests simulating user behaviours. It usually starts with developing the scenario. After making sure that monitoring is in place, the load testing can start. Now we can learn how the system behaves and what to expect in the production environment.

Summing it up

It is very important:

to know what functionalities are needed and enabled on the server
to verify if a custom extension is already covered in a XEP
to only build a custom extension if necessary
to run load tests to find the capacity and be better prepared for the real traffic

All of the above may not be rocket science; many services run on MongooseIM without our help.

If you are up to the challenge, good, we are always happy to see our product in use.

But, when your time is critical, or if you stumble upon a problem you can't fix, we're happy to help. If hacking through 80K lines of unknown code is not your cup of tea, we can guide you through it. Stay safe and have fun adding real-time communication to your product, if required.

Webinar: Data scraping made easy in Elixir

Erlang Solutions — Tue, 23 Jun 2020 10:38:59 +0000

Following up from his talk at ElixirConf EU Virtual, our colleague Oleg Tarasenko will be joining us on the webinar to dive deeper into Crawly, the web scraping framework he created in Elixir.

In this webinar he will discuss what web scraping is, why it is valuable and how Crawly makes it easy.

The webinar will demonstrate a real example using the Elixir Radar job board.

Businesses are investing in data. The big data analytics market is expected to grow to $103 billion (USD) within the next five years. It’s easy to see why, with everyone of us on average generating 1.7 megabytes of data per second.

As the amount of data we create grows, so too does our ability to inherent, interpret and understand it. Taking enormous datasets and generating very specific findings are leading to fantastic progress in all areas of human knowledge, including science, marketing and machine learning.

Learn how to gather valuable data with web scraping in Elixir. Register for our webinar at https://www2.erlang-solutions.com/crawlywebinar2

Why Elixir is the Programming Language You Should Learn in 2020

Erlang Solutions — Mon, 15 Jun 2020 10:02:59 +0000

What should you look for when choosing to learn a new programming language? The answer might vary depending on what your project or career goals are, but as a basic starting point, you want a language that:

Is fun and easy to use
Has the ability to meet modern user demands
Has rewarding career progression
Has an active and supportive community
Has a range of helpful tooling
Has frameworks to allow full-stack development
Has easily accessible documentation
Ensures you grow as a programmer.

Over the course of the article, we'll show you how Elixir rates in relation to all of the above dot points. Before we start, it's worth letting you know a little bit about me. I like to consider myself a polyglot developer. Over the years I have worked with Elm, Lua, Rust, Dart, Go, Kotlin, Scala, C, C++, Perl, Ruby, PHP, Python, Java, JavaScript, Erlang and Elixir. If I were to only pick one language to learn as a brand new developer in 2020, it would be Elixir.

Why Elixir is fun and easy to use

Fun might not be the only important consideration, but it is one that should not be underestimated. Elixir's syntax shares a lot of similarities with Ruby; both are high-level, readable, fun programming languages. As a senior developer from Pinterest once said of his decision to transition to Elixir:

""I thought, 'Wow, it's as fun as Ruby, but it has some chops — it actually performs really well.'"

Personally, I love the ability to write less code. It is a language that is expressive enough to be understandable and fast to read. For example, using the Tesla library, I could implement integration with a provider like Paypal in 20 lines of code. I will be happy to schedule a hands-on workshop or a 1-on-1 call if there is a need for dive into this library.

How Elixir has the ability to meet modern usage demands

We all heard of the digital transformation, right? As populations grow, and more services move online there is increased pressure on systems to be able to handle huge spikes with billions of concurrent users.

Elixir runs on the BEAM VM. A system built for concurrency. As a result, it can handle these user spikes with ease. For those interested in what concurrency is, and how it works, we have a blog comparing the JVM and BEAM VM, which explains it well.

Pinterest and Bleacher Report are just two of widely popular and big companies who moved to Elixir in order to help solve issues of scalability. In the case of Bleacher Report, one of our clients, they were able to move from 150 servers, down to 5 servers. Not only did they reduce there physical infrastructure requirements, they were also able to handle more traffic with faster times. A language that can be relied upon for scalable, fault-tolerant will always be sought out by high profile companies.

Elixir’s rewarding career progression

Elixir is a growing language which is being adopted at a significant rate. As a result, Elixir developers have the opportunity to work for wide spectrum of companies such as PepsiCo, Pinterest, Lonely Planet or MBTA. And the list is continuing to grow. Check out this list for companies added in the last 12 months alone.

The supportive and active Elixir community

As you might expect with any new technology or programming language, the Elixir community started out small.

Nowadays Elixir has a thriving community that continues to grow, with fantastic events such as ElixirConf in Europe and in the US, EMPEX, Code Elixir LDN and Gig City Elixir, as well as Meetups all around the world. This community means the language is continuing to grow and evolve with new tooling, and that there is always someone to provide inspiration or help find solutions to a problem.

Elixir’s range of useful tooling

Tooling makes languages more versatile and tasks easier. They mean that you don't have to reinvent the wheel with every new use case. Elixir already has a number of powerful tools, including Phoenix LiveView which enables developers to build real-time, front-end web applications without writing a line of JavaScript or Crawly which makes web crawling and Data Scraping in Elixir easy. Not only does Elixir have a wide-variety of tooling available, but as we mentioned earlier, there is also a passionate community of people continually creating new tools and improving the ones available.

Elixir frameworks allow for full-stack development

Given its scalability performance and its origins in Erlang, it is no surprise that Elixir is a popular backend choice. As mentioned above, Phoenix LiveView has provided an easy, time-efficient and elegant way for Elixir developers to produce front-end applications. Finally, the Nerves framework allows for embedded software development on the hardware end. As a result, Elixir is a language that can be adopted right throughout the tech stack. This doesn't just make it an attractive choice for businesses; it also opens up the door for where the language can take you as a developer.

Elixir’s easily accessible documentation

A language and community where documentation is valued is one that makes knowledge sharing easy. The high standard of documentation in the Elixir community makes it easier for you to learn the language, but also, make it easier for anyone to contribute to its improvement and growth.

Learning Elixir can make you a better programmer in other languages

There are a number of stories, from people who come from object-oriented languages, who found that the process of learning Elixir made them a better programmer in their language of choice. Learning a new purely functional programming paradigm forces you to examine the way you approach programming. In doing so, it can help you identify habits that can be improved and introduce you to new ways of thinking about problems. This fresh perspective is invaluable for all future development you do, regardless of what language you are working with. For our friends using Ruby, this is particularly true, as the Elixir syntax will be familiar to you, allowing you an easy transition into functional, concurrent programming.

Everyone will have different motivation and considerations for what programming language to choose. But these are the reasons I would recommend you learn Elixir in 2020, for the years ahead.

Ready to get started in Elixir?

There are many ways to start. First, you should head to the getting started page of the official Elixir website. We also offer a number of free downloadable packages for Elixir.

Secondly, we offer a variety of Elixir training, including our Elixir Programming Training For Beginners.

To get started in the community ElixirForum is a great place to start, as well as searching the #Elixirlang and #MyElixirStatus hashtags on Twitter.

Using RabbitMQ for microservice architecture success - Guest Blog by API Fortress API

Erlang Solutions — Thu, 12 Mar 2020 10:45:26 +0000

API Fortress is an automated continuous testing platform for APIs that can be deployed in-house or on the cloud. Thier list of clients includes GoPro, Getty Images and MuleSoft (just to name a few). We had the pleasure of speaking to their CTO and co-founder, Simone Pezzano to discuss the journey they underwent to choosing RabbitMQ for their microservices architecture, why they felt it was the right tool for the job and how they've used its capabilities to build a succesful platform. The result is great example of how and why to move to RabbitMQ for a long-term harmonious micro-service architecture with improved performance.

API Fortress and RabbitMQ - The discovery phase

The initial concept of API Fortress was born in 2014. They were working with APIs for various companies, and realized that there was no system to test and monitor the APIs without writing a test suite in code. After searching the market, they realized there was a definite need for a better, more modern approach to testing and monitoring, so they started building our platform.

In the early days, as they were gaining customers, they gathered critical insight about the most common testing and monitoring use cases. One of the top use cases involved a transition from legacy monolithic systems to a more contemporary microservices architecture. This trend had dovetailed with the explosion of APIs and API management platforms like Apigee, Mulesoft, Mashery, WSO2, and Kong, etc.

In 2016, they decided to undergo that change, and converted their platform into an entirely microservices-based architecture. During that process, they realized that it was very important that the platform leverage a tool capable of seamlessly orchestrating asynchronous messaging across heterogeneous components. This tool would need to indicate the importance of each message, pointing to whether the message represented a notification or an important task to execute. During setup, it would need to help us scale our microservices-based platform as much as needed horizontally for a multi-tenant cloud system but with negligible overhead, which was highly desirable for our situation. Additionally, it would need the tool to be able to deploy with our platform on-premises.

Their search for the right tool led them to RabbitMQ. Not only would RabbitMQ let them reach the goals of API Fortress, several unique features of RabbitMQ opened a whole new set of possibilities. In fact, they planned several key architectural improvements based on the new capabilities found in RabbitMQ, including:

RabbitMQ’s powerful message routing settings allowed us to better shape the flow of events throughout our platform. By increasing the efficacy of each message, we reduced the complexity caused by message replication, and subsequent remedial actions in case of failure.
Standardized AMQP protocol and STOMP support allowed us to create message queues that were not just internal, but also usable by our customers when reacting to certain events with their internally built software in any language.
High configurability of Queues and Exchanges using the default client libraries in RabbitMQ allowed us to delegate 100% of the setup operations to the pieces of software that actually use the queues, reducing the uncertainty introduced by custom maintenance sequences.
The costs and skill requirements for day-to-day maintenance dropped to virtually zero.

RabbitMQ provided all of these features and more with unparalleled stability and a minimal resource footprint. Whether powering our cloud platform with thousands of messages being exchanged, or our Docker on-premises deployment, RabbitMQ is the component helping to drive our platform’s success.

The API Fortress Architecture

To help better understand how RabbitMQ solved many past problems for API Fortress, but then also opened our architecture to new possibilities, we can take a deeper dive into how RabbitMQ infiltrates into all aspects of the API Fortress platform in the following:

While it may seem a little intimidating in its complexity, the key factor to understand is that RabbitMQ literally coordinates the majority of all API Fortress microservices. Without going into too much detail, here are several factors that should be highlighted on that point.

Microgateway-to-Storage

RabbitMQ gives a quick solution to allow the microgateway to not care how the messages are delivered by simply asking RabbitMQ to take care of the payloads. This approach allows the Storage Microservice to only accept as much load as it can possibly bear, leveraging RabbitMQ's QoS as it writes the payloads to the database.

Scheduler-to-Engines

Tests may fail to execute properly when accepted by one of the engines, however, the .ack-.nack system in RabbitMQ makes sure that if it happens, the test can immediately be requeued to execute later. Combined with the the QoS system, we can accurately decide how much load each engine is allowed to accept, making sure the platform does not get congested. To add some extra spice to this, each message from the scheduler can be configured with a given execution priority, which is a very desirable option, especially when thousands of tests are scheduled every five minutes, and some of them are more time-sensitive than others. Finally, as tests get accepted and acknowledged at a somewhat relatively slow rate, RabbitMQ Flow Control can apply back pressure to the Scheduler so that the queue maintains a reasonable size.

Engines-to-Downloaders

Downloaders are microservices that perform I/O operations on behalf of an engine. While this communication is generally solved with an HTTP call, some downloaders may live on-premises behind a firewall. RabbitMQ comes to the rescue offering us two solutions:

An RPC-like functionality that allows an entity (in this case, the engine) to ask for something (to the downloader) and then expect a response
A STOMP connector that allows us to expose a dedicated queue as a websocket. The combination of these two features allows us to deploy the downloader on-premises, initiating a stable channel from the inside of the third-party datacenter and bypassing inbound firewall rules.

Engines-to-Notification

Multiple aspects of a test execution may need to be notified to users in a variety of ways. In our system, the Mailer sends emails while the Connector triggers Web Hooks. Third-party notification systems can also be added in the mix, with the internal notification system completing the picture. RabbitMQ Fan-out exchanges allow multiple notification systems to subscribe to the messages they're interested in and just receive them as they are made available.

Notification-to-Engine

Sometimes, notification systems may need certain types of extra information to complete their jobs, e.g., email recipients. Because, by design, they don't have access to the database, notification systems leverage the same RPC-like system we previously mentioned to ask the Engines for the information they're missing without the need to discover what engines are available, where they live, and how healthy they are, etc.

In Conclusion

API Fortress undertook the same journey as many of their customers. Everyday, thousands of customers leverage the API Fortress platform as they transform from a monolithic architecture to microservices. By leveraging RabbitMQ, much like their customers who are working towards event-driven architectures and other patterns, they have established the foundation to grow and expand their capabilities without sacrificing performance.

To learn more about the automation of continous API testing, check out the API Fortress website.

Speak to us about how we can help with RabbitMQ

Our world-leading RabbitMQ team offers a variety of options to suit your needs. We have everything from health checks, to support and monitoring, to help you ensure an efficient and reliable RabbitMQ system. If you're inspired to look at how RabbitMQ can help you improve your microservice architecture or move away from monolith legacy systems, talk to our RabbitMQ experts.

Or, if you’d like to have full visibility of your RabbitMQ system from an easily readable dashboard, why not take advantage of the free trial of our WombatOAM monitoring solution.