Turning up your observability to 11 with Fluent Bit

Fluentd has been a dominant solution in the CNCF portfolio of projects for log capture and distribution. But it has a new challenger, its sibling Fluent Bit.

In this session, we’ll look at how Fluent Bit is raising the game when it comes to log management and observability with integration with OpenTelemetry, transparent connectivity with existing Fluentd deployments, and built-in stream processing.
We’ll illustrate how Fluent Bit’s advancements with a couple of simple demos.

Fluent Bit, the engine to power Chat Ops

The key to successful Chat Ops is to be able to identify the important information in a timely manner using the best comms channel for a team (e.g., Slack or a bespoke App) & enable the ops to act.

Fluent Bit has a number of core characteristics (event-driven & stream processing) that allow us to recognize critical events as they occur and support typical log analytics and observability tools. Using Fluent Bit’s features allows us to spot critical events and immediately communicate with the right ops staff using social channels in a flexible and versatile manner and return actions to trigger suitable remediation, creating the chance to react more quickly & even become proactive/preventative.

In this session, we’ll see the capabilities of Fluent Bit that can not just get data to the mainstream observability tools but also help us to respond faster & may be pre-emptively using a thought-provoking demo. So that we care for our ‘pets’ or avoid the ‘cattle’ stampeding.

Monoliths in a Microservice World

The goals and values of adopting a microservice design methodology have been well documented. So why might a monolith approach be valid, and why do some organizations reject the microservice model? In this session, we'll look at the challenges involved in the adoption of microservices and when it makes sense to stick with a monolith delivery model, and when we may think we're building microservices. Still, the reality is we have a monolith using new technologies.

Attendees will takeaway from the session:
• A look at conditions where adopting microservices may not deliver on its promises
• A view on approaches that can allow monoliths and microservices can co-exist successfully
• Insights from organizations who have rejected microservices and what a middle ground can look like

Stop Polling, Let’s go Streaming – A more efficient API paradigm

For many years APIs have been implemented so that the client has to keep calling the server for the latest data. The API version of needing to refresh your browser. But this can be inefficient, and wasteful in addition to risking clients using old data.

Techniques like Webhooks and network sockets have been around for a while, but new ways to implement API streams have come along.

In this session, we’ll look at how the different common options are, how they work, and their drawbacks. By the end of this session, you will have the knowledge to make a more informed decision on whether streaming APIs are right for you and which approach may support your needs best.

Is a Kubernetes Ingress Controller good enough to be an API Gateway?

As Kubernetes becomes increasingly pervasive, we’ve seen the development of ingress controllers to claim the role of an API Gateway. On the surface, this may look fine and certainly takes advantage of K8s’ sophistication, but is it right?

In this session, we’ll explore what we should expect from gateways in different use cases, whether such requirements can be appropriately satisfied using an ingress controller.

Microservices in a Monolith World

There is no doubt that a large proportion of the IT industry sees microservices as the direction of travel for development. But transitioning to this software delivery model can be profoundly disruptive in technology, organization, and process. Much like how becoming truly Agile has been difficult, organizations often end up with Wagile (waterfall with agile where the project is managed in a waterfall model, but agile ceremonies are used to manage day-to-day activities).

In this light, what can we do to make the transition to microservices easier? What is it we're really trying to get from adopting microservices? In this session, we'll describe some of the approaches Capgemini have used with customers to help reach a place where a microservice way of building, delivering, and operating software solutions can work. We'll look at why some organizations have openly said microservices haven't worked for them and why, and importantly not using microservices should not be seen as a failure.

Good APIs - more than just a payload definition

When defining APIs the most common considerations are from what our payload looks like, and then from a implementer perspective.

However, good APIs whether they’re internal or public are far more than just a payload description and need a consumer’s perspective.

In this session we look at what makes up a good API; from OWASP Top 10 implications to ISO and data definitions, to how to make it easy for your consumers, why these points are important and the implications. We’ll explore techniques to overcome of the challenges seen when producing good APIs.

Whilst we all think we know how to define APIs, you’ll be surprised at the things that get overlooked or opportunities to be better.

REST, GraphQL, gRPC APIs and streaming APIs - what should I use?

REST has displaced the use of SOAP+WSDL but GraphQL and gRPC are rapidly gaining mainstream adoption, are these going to displace REST? Not only are we seeing the way to make AP calls evolving, but are starting to offer streaming options.
So which technologies(s) are best for my API needs? When should I adopt API streaming, and can I stop using Messaging platforms?
In this session, we’ll explore and illustrate the characteristics, strengths, and weaknesses of these technologies and how they fit different use cases.

we'll demo a couple of solutions to help illustrate the differences

Making Logs Work for you with Fluentd

Understanding what is happening with a distributed solution can be challenging. Whilst the solution space for monitoring and application log management is mature, there is a tendency for organizations to end up with multiple tools which overlap in this space to meet different team needs – result multiple agents/probes on every server. Many of these tools work by bulk central analysis rather than enabling events of interest to be spotted as they’re logged.

Fluentd presents us with a means to simplify the monitoring landscape, address challenges of hyper-distribution occurring with microservice solutions, allowing different tools needing log data to help in their different way. Without imposing a specific analysis tool on relevant teams.

In this session, we’ll explore the challenges of modern log management. We’ll look at how Fluentd works and what it can bring to making both development and ops activities easier. To do this we’ll explore and demos some examples of Fluentd and how it makes life easier & more efficient.

FluentD - Making logging easy and effective in multicloud and hybrid

Understanding what is happening with a solution that is built from multiple components can be challenging. While the solution space for monitoring and application log management is mature, there is a tendency for organizations to end up with multiple tools which overlap in this space to meet different team needs. They also work on aggregate then act, rather than consider things in a more granular way.
FluentD presents us with a means to simplify the monitoring landscape, address challenges of hyper-distribution occurring with microservice solutions, allowing different tools needing log data to help in their different way.
In this session, we’ll explore the challenges of modern log management. How its use can make hybrid and multi-cloud solutions easy to monitor.

Why become a tech author, what does it take, and how does it help me?

Regardless of what we’re trying to understand, we will turn to a book sooner or later. For the IT community and the open-source developer community, particularly where you could read the code, there has long been advocacy that good code doesn’t need documentation. We still read and buy books.

So what does it take to write a book, and what motivates people to write a book? Finally, if you write a tech book will you be able to go to developer heaven and code what you want, when you want, for whatever reason you want?

I’ll share my lessons and research in this session, dispel some myths, and maybe inspire you to start your own journey.