Welcome to Developer Week 2024

Post Syndicated from Rita Kozlov original https://blog.cloudflare.com/welcome-to-developer-week-2024


It’s time to ship. For us (that’s what Innovation Weeks are all about!), and also for our developers.

Shipping itself is always fun, but getting there is not always easy. Bringing something from idea to life requires many stars to align. That’s what this week is all about — helping developers, including the two million developers already building on our platform, bring their ideas to life.

The full-stack cloud

Building applications requires assembling many different components.

The frontend, the face of the application, must be intuitive, responsive, and visually appealing to engage users effectively. Behind the scenes, you need a backend to handle data processing, storage, and retrieval, ensuring smooth functionality and performance. On top of all that, in the past year AI has entered the chat, so to speak, and increasingly every application requires an element of AI, making it a crucial part of the stack.

The job of a good platform is to provide all these components, and any others you will need, to you, the developer.

Just as there’s nothing more frustrating than coming home from the grocery store and realizing you left out an ingredient, realizing a platform is missing a major component or piece of functionality is no different.

We view providing the tooling that developers need as a critical part of our job as a platform, which is why with every Developer Week, we make it our mission to provide you with more and more pieces you may need. This week is no different — you can expect us to announce more tools and primitives from the frontend to backend to AI.

However, our job doesn’t stop there. If a good platform provides the components, a great platform goes a step further than that.

The job of a great platform is not only to provide the components, but make sure they play well with each other in a way that makes your job as a developer easier. Our vision for the developer platform is exactly that: to anticipate not just the tools you need but also think about how they work with each other, and how they integrate into your development flow.

This week, you will see announcements and deep dives that expound on our vision for an integrated platform: pulling back the curtain on the way we expose services in Workers through bindings for an integrated developer experience, talking about our vision for a unified data platform, updating you on framework support, and more.

The connectivity cloud

While we’re excited for you to build on us as much as possible, we also realize that development projects are rarely greenfield. If you’ve been at this for a long time, chances are a large portion of your application already lives somewhere, whether on another cloud, or on-prem.

That’s why we’re constantly making it easier for you to connect to existing infrastructure or other providers, and working hard to make sure you can still reap the benefits of building on Cloudflare by making your application feel fast and global, regardless of where your backend is.

And vice versa, if your data is on us, but you need to access it from other providers, it’s not our job to keep it hostage in a captivity cloud by charging a tariff for egress.

The experimentation cloud

Before you start assembling components, or even coming up with a plan or a spec for it, there’s an important but overlooked step to the development process — experimentation.

Experimentation can take many forms. Experimentation can be in the form of prototyping an MVP before you spend months developing a product or a feature. If you’ve found yourself rewriting your entire personal website just to try out a new tool or framework, that’s also experimentation.

It’s easy to overlook experimentation as a part of the process, but innovation doesn’t happen without it, which is why it’s something we always want to encourage and support as a part of our platform.

That’s why offering a generous free tier is something that’s been a part of our DNA since the very beginning, and something you can expect to forever be a staple of our platform.

The demo to production cloud

Alright, you’ve got all the tools you need, you’ve had a chance to experiment, and at some point… it’s time to ship.

Shipping is exciting, but shipping is also vulnerable and scary. You’re exposing the thing you’ve been working hard on to the world to criticize. You’re exposing your code to a world of untested edge cases and abuse. You’re exposing your colleagues who are on call to the possibility of getting paged at 1 AM due to the code you released.

Of course, the wrong answer is not shipping.

The right answer is having a platform that supports you and holds your hand through the scary parts. This means a platform that can seamlessly scale from zero to sixty. A platform gives you the tools to test your code, and release it gradually to the world to help you gain confidence. Or a platform provides the observability you need when you are trying to figure out what’s gone wrong at 1 AM.

That’s why this week, you can look forward to some announcements from us that we hope will help you sleep better.

The demo to production cloud — for inference

We talked about some of the scary parts of deploying to production, and while all these apply to AI as well, building AI applications today, especially in production, presents its own unique set of challenges.

Almost every day you see a new AI demo go viral — from Sora to Devin, it’s easy and inspiring to imagine our world completely changed by AI. But if you’ve started actually playing with and implementing AI use cases, you know the harsh reality of making AI truly work. It requires a lot of trial and error to get the results you want — choosing a model, RAG, fine-tuning…

And that’s before you even go to production.

That’s when you encounter the real challenge — provisioning enough capacity to stay up, without over-provisioning and overpaying. This is the exact challenge we set out to solve from the early days of Workers — helping developers not worry about infrastructure, just the application they want to build.

With the recent rise of AI, we’ve noticed many of these challenges return. Thankfully, managing loads and infrastructure is what we’re good at here at Cloudflare. It’s what we’ve had practice at for over a decade of running our platform. It’s all just one giant scheduler.

Our vision for our AI platform is to help solve the exact challenges in deploying AI workloads that we’ve been helping developers solve for, well, any other type of workload. Whether you’re deploying directly on us with Workers AI, or another provider, we’ll help provide the tools you need to access the models you need, without overpaying for idle compute.

Don’t worry, it’s all going to be fine.

So what can you expect this week?

No one in my family can keep a secret — my sister cannot get me a birthday present without spoiling it the week before. For me, the anticipation and the look of surprise is part of the fun! My coworkers seem to have clued into this.

While I won’t give away too much, we’ve already teased out a few things last week (you can find some hints here, here and here), as well as in this blog post if you read closely (because as it turns out, I too, can’t help myself).

See you tomorrow!

Our series of announcements starts on Monday, April 1st. We look forward to sharing them with you here on our blog, and discussing them with you on Discord and X.

A few relevant quotes

Post Syndicated from corbet original https://lwn.net/Articles/967420/

I’m on a holiday and only happened to look at my emails and it
seems to be a major mess.

— Lasse Collin

The reality that we are struggling with is that the free software
infrastructure on which much of computing runs is massively and
painfully underfunded by society as a whole, and is almost entirely
dependent on random people maintaining things in their free time
because they find it fun, many of whom are close to burnout. This
is, in many ways, the true root cause of this entire event.

— Russ Allbery

Incredible work from Andres. The attackers made a serious
strategic mistake: they made PostgreSQL slightly slower.

— Thomas
Munro

There is no way to discuss this in public without turning a single
malicious entity into 10 000 malicious entities once the
information is widely known.

Making sure the impact and mitigations are known before posting
this publicly so that everyone knows what to do before the 10 000
malicious entities start attacking is just common sense.

— Marc
Deslauriers

Again the FOSS world has proven to be vigilant and proactive in
finding bugs and backdoors, IMHO. The level of transparency is
stellar, especially compared to proprietary software
companies. What the FOSS world has accomplished in 24 hours after
detection of the backdoor code in #xz deserves a moment of
humbleness. Instead we have flamewars and armchair experts shouting
that we must change everything NOW. Which would introduce even more
risks. Progress is made iteratively. Learn, adapt, repeat.

— Jan Wildeboer

Седмицата (25–30 март)

Post Syndicated from original https://www.toest.bg/sedmitsata-25-30-mart/

Тайната на грънчаря е, че всеки път започва отначало. Същото се отнася за нашия герой – Хираяма. Всеки ден той започва отначало. Не мисли как го е направил вчера или как ще го направи утре. Винаги го прави на момента. Това е още една от тайните на грънчаря, който придава различна красота на всяко повторение.
Вим Вендерс

Седмицата (25–30 март)

В последния уикенд на „София Филм Фест“ все още имате възможност да гледате „Прекрасни дни“ – най-новия филм на режисьора Вим Вендерс, който представлява дълбоко вълнуващ и поетичен разказ за откриването на красота в ежедневието. То може да бъде толкова натоварващо и изпълнено със стрес и тревоги, но винаги крие в себе си и неподозирани късчета красота. Ние се стараем да ви помагаме да ги откриете дори когато изглежда много трудно.

От гледна точка на политическите новини дните от изминалата седмица не са точно прекрасни. Оказва се невъзможно да се намери нов служебен премиер и ситуацията е толкова предизвикателна, а досегашните предложения – нелепи и несполучливи, че дори беше създаден сайт „Министър ли съм?“ с отговор на въпроса попаднали ли сме случайно в списъка с министерски номинации… Много се говори как държавата ще изпадне в конституционна криза. Но Емилия Милчева смята, че това са само внушения, и в своя седмичен анализ „Български политически животни“ разсъждава колко висок е потенциалът на родните политически фигури, повели обществото към шести парламентарни избори за последните три години.

По повод 20-тата годишнина от членството на България в НАТО президентът Румен Радев направи равносметка и обобщи, че всички държави членки са длъжни да обединяват потенциал, усилия и ресурси, за да може да развиват военна наука, високи технологии, Космос и изкуствен интелект. И докато вървят красиви речи за международен мир, сигурност и справедливост, в същото това време МВР е заето с търсене на поводи за увеличаване на полицейското присъствие в София. Въоръжените полицаи, патрулиращи по улиците, карат ли ви да се чувствате в по-голяма безопасност? Светла Енчева си задава въпроса дали тези акции, тип „Въоръжена бдителност по никое време“, са продиктувани от загриженост за гражданите, или са по-скоро бутафорно присъствие с цел печелене на предизборни точки за показна активност.

В опит да отместим фокуса от тези проблеми отново повдигаме завесата над също не особено приятната тема за качеството на медицинската помощ у нас. Според закона, когато пациент отиде в лечебно заведение, той има право да очаква, а медицинският персонал е длъжен да му оказва такава медицинска помощ, която е утвърдена и в медицинската теория, и в практиката. Уви, реалността често се разминава с предписаното в закона. В „Грешка 404: Здравеопазване по неправилно зададени параметри“ Надежда Цекулова повдига важни въпроси в интервю с адв. Мария Шаркова, създателка на уебсайта „Лекарска грешка“, който събира статистика за делата по случаите, наречени в правото „медицински деликти“.

След подробното запознаване с наболели въпроси от седмицата на човек внезапно му се приисква просто тихомълком да излезе от света на новините. И тук на помощ се притичва редовната ни рубрика „От дума на дума“, в която тази седмица получаваме подробно разяснение на всички възможни начини за изсулване, тоест за елегантно измъкване, макар че „Винаги другите са тези, които се измъкват (по терлици)“, както е озаглавила текста си този път Екатерина Петрова.

Почти накрая, но не и по важност, ето и една великолепна инициатива, която не бива да пропускате: най-популярният, заслужил репутацията си през годините езиков справочник „Как се пише?“ обедини усилия с екипа на The Huts Group, за да направят заедно дигитално помагало в помощ на дипломиращите се дванайсетокласници. Под надслов „Животът няма „аУтокорект“ от днес до деня на матурата по български език и литература (17 май) в профила на „Как се пише?“ в Threads ще се публикуват тестови въпроси, съобразени изцяло с формата на държавния зрелостен изпит по БЕЛ. Колко често? Всеки ден. Защото „Как се пише?“ вече не е просто важен въпрос, а неотложен.

Краят на месеца е и няма да ви оставим без стихотворение… дори и то да напомня, че „В ада без изход и ние бяхме…“. Йоан Ес. Поп е един от живите класици на съвременната румънска поезия, а чудесният превод е на Лора Ненковска. За щастие, поезията продължава да съществува, за да ни предлага алтернатива на грубата реалност… или поне различен поглед към нея в опит да я осмислим по-добре. 

Зорница Христова отлично разбира тази необходимост и съвсем уместно е избрала да ни представи в рубриката „По буквите“ един от най-големите съвременни английски поети – Филип Ларкин, с последната му стихосбирка „Високи прозорци“. Какво липсва в дните? Нещо, което да не е мираж, нито неумело самозалъгване, нито лъжа…

В седмичните анализи на „Тоест“ май нищо не липсва. 

Приятно четене!

Friday Squid Blogging: The Geopolitics of Eating Squid

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2024/03/68676.html

New York Times op-ed on the Chinese dominance of the squid industry:

China’s domination in seafood has raised deep concerns among American fishermen, policymakers and human rights activists. They warn that China is expanding its maritime reach in ways that are putting domestic fishermen around the world at a competitive disadvantage, eroding international law governing sea borders and undermining food security, especially in poorer countries that rely heavily on fish for protein. In some parts of the world, frequent illegal incursions by Chinese ships into other nations’ waters are heightening military tensions. American lawmakers are concerned because the United States, locked in a trade war with China, is the world’s largest importer of seafood.

As usual, you can also use this squid post to talk about the security stories in the news that I haven’t covered.

Read my blog posting guidelines here.

Amazon GuardDuty EC2 Runtime Monitoring is now generally available

Post Syndicated from Channy Yun original https://aws.amazon.com/blogs/aws/amazon-guardduty-ec2-runtime-monitoring-is-now-generally-available/

Amazon GuardDuty is a machine learning (ML)-based security monitoring and intelligent threat detection service that analyzes and processes various AWS data sources, continuously monitors your AWS accounts and workloads for malicious activity, and delivers detailed security findings for visibility and remediation.

I love the feature of GuardDuty Runtime Monitoring that analyzes operating system (OS)-level, network, and file events to detect potential runtime threats for specific AWS workloads in your environment. I first introduced the general availability of this feature for Amazon Elastic Kubernetes Service (Amazon EKS) resources in March 2023. Seb wrote about the expansion of the Runtime Monitoring feature to provide threat detection for Amazon Elastic Container Service (Amazon ECS) and AWS Fargate as well as the preview for Amazon Elastic Compute Cloud (Amazon EC2) workloads in Nov 2023.

Today, we are announcing the general availability of Amazon GuardDuty EC2 Runtime Monitoring to expand threat detection coverage for EC2 instances at runtime and complement the anomaly detection that GuardDuty already provides by continuously monitoring VPC Flow Logs, DNS query logs, and AWS CloudTrail management events. You now have visibility into on-host, OS-level activities and container-level context into detected threats.

With GuardDuty EC2 Runtime Monitoring, you can identify and respond to potential threats that might target the compute resources within your EC2 workloads. Threats to EC2 workloads often involve remote code execution that leads to the download and execution of malware. This could include instances or self-managed containers in your AWS environment that are connecting to IP addresses associated with cryptocurrency-related activity or to malware command-and-control related IP addresses.

GuardDuty Runtime Monitoring provides visibility into suspicious commands that involve malicious file downloads and execution across each step, which can help you discover threats during initial compromise and before they become business-impacting events. You can also centrally enable runtime threat detection coverage for accounts and workloads across the organization using AWS Organizations to simplify your security coverage.

Configure EC2 Runtime Monitoring in GuardDuty
With a few clicks, you can enable GuardDuty EC2 Runtime Monitoring in the GuardDuty console. For your first use, you need to enable Runtime Monitoring.

Any customers that are new to the EC2 Runtime Monitoring feature can try it for free for 30 days and gain access to all features and detection findings. The GuardDuty console shows how many days are left in the free trial.

Now, you can set up the GuardDuty security agent for the individual EC2 instances for which you want to monitor the runtime behavior. You can choose to deploy the GuardDuty security agent either automatically or manually. At GA, you can enable Automated agent configuration, which is a preferred option for most customers as it allows GuardDuty to manage the security agent on their behalf.

The agent will be deployed on EC2 instances with AWS Systems Manager and uses an Amazon Virtual Private Cloud (Amazon VPC) endpoint to receive the runtime events associated with your resource. If you want to manage the GuardDuty security agent manually, visit Managing the security agent Amazon EC2 instance manually in the AWS documentation. In multiple-account environments, delegated GuardDuty administrator accounts manage their member accounts using AWS Organizations. For more information, visit Managing multiple accounts in the AWS documentation.

When you enable EC2 Runtime Monitoring, you can find the covered EC2 instances list, account ID, and coverage status, and whether the agent is able to receive runtime events from the corresponding resource in the EC2 instance runtime coverage tab.

Even when the coverage status is Unhealthy, meaning it is not currently able to receive runtime findings, you still have defense in depth for your EC2 instance. GuardDuty continues to provide threat detection to the EC2 instance by monitoring CloudTrail, VPC flow, and DNS logs associated with it.

Check out GuardDuty EC2 Runtime security findings
When GuardDuty detects a potential threat and generates security findings, you can view the details of the healthy information.

Choose Findings in the left pane if you want to find security findings specific to Amazon EC2 resources. You can use the filter bar to filter the findings table by specific criteria, such as a Resource type of Instance. The severity and details of the findings differ based on the resource role, which indicates whether the EC2 resource was the target of suspicious activity or the actor performing the activity.

With today’s launch, we support over 30 runtime security findings for EC2 instances, such as detecting abused domains, backdoors, cryptocurrency-related activity, and unauthorized communications. For the full list, visit Runtime Monitoring finding types in the AWS documentation.

Resolve your EC2 security findings
Choose each EC2 security finding to know more details. You can find all the information associated with the finding and examine the resource in question to determine if it is behaving in an expected manner.

If the activity is authorized, you can use suppression rules or trusted IP lists to prevent false positive notifications for that resource. If the activity is unexpected, the security best practice is to assume the instance has been compromised and take the actions detailed in Remediating a potentially compromised Amazon EC2 instance in the AWS documentation.

You can integrate GuardDuty EC2 Runtime Monitoring with other AWS security services, such as AWS Security Hub or Amazon Detective. Or you can use Amazon EventBridge, allowing you to use integrations with security event management or workflow systems, such as Splunk, Jira, and ServiceNow, or trigger automated and semi-automated responses such as isolating a workload for investigation.

When you choose Investigate with Detective, you can find Detective-created visualizations for AWS resources to quickly and easily investigate security issues. To learn more, visit Integration with Amazon Detective in the AWS documentation.

Things to know
GuardDuty EC2 Runtime Monitoring support is now available for EC2 instances running Amazon Linux 2 or Amazon Linux 2023. You have the option to configure maximum CPU and memory limits for the agent. To learn more and for future updates, visit Prerequisites for Amazon EC2 instance support in the AWS documentation.

To estimate the daily average usage costs for GuardDuty, choose Usage in the left pane. During the 30-day free trial period, you can estimate what your costs will be after the trial period. At the end of the trial period, we charge you per vCPU hours tracked monthly for the monitoring agents. To learn more, visit the Amazon GuardDuty pricing page.

Enabling EC2 Runtime Monitoring also allows for a cost-saving opportunity on your GuardDuty cost. When the feature is enabled, you won’t be charged for GuardDuty foundational protection VPC Flow Logs sourced from the EC2 instances running the security agent. This is due to similar, but more contextual, network data available from the security agent. Additionally, GuardDuty would still process VPC Flow Logs and generate relevant findings so you will continue to get network-level security coverage even if the agent experiences downtime.

Now available
Amazon GuardDuty EC2 Runtime Monitoring is now available in all AWS Regions where GuardDuty is available, excluding AWS GovCloud (US) Regions and AWS China Regions. For a full list of Regions where EC2 Runtime Monitoring is available, visit Region-specific feature availability.

Give GuardDuty EC2 Runtime Monitoring a try in the GuardDuty console. For more information, visit the Amazon GuardDuty User Guide and send feedback to AWS re:Post for Amazon GuardDuty or through your usual AWS support contacts.

— Channy

Metasploit Weekly Wrap-Up 03/29/2024

Post Syndicated from Brendan Watters original https://blog.rapid7.com/2024/03/29/metasploit-weekly-wrap-up-03-29-2024/

PHP code execution and Overshare[point]

Metasploit Weekly Wrap-Up 03/29/2024

Here in the Northern Hemisphere, Spring is in the air: flowers, bees, pollen… a new Metasploit 6.4 release, and now, fresh on the heels of this new release is a bountiful crop of exploits, features, and bug-fixes. Leading the pack is a pair of 2024 PHP code execution vulnerabilities in Artica Proxy and the Bricks Builder WordPress theme, and not to be outshone is a pair of Sharepoint vulnerabilities chained to give unauthenticated code execution as administrator.

New module content (3)

Artica Proxy Unauthenticated PHP Deserialization Vulnerability

Authors: Jaggar Henry of KoreLogic Inc. and h00die-gr3y [email protected]
Type: Exploit
Pull request: #18967 contributed by h00die-gr3y
Path: linux/http/artica_proxy_unauth_rce_cve_2024_2054
AttackerKB reference: CVE-2024-2054

Description: The PR adds a module targeting CVE-2024-2054, a command injection vulnerability in Artica Proxy appliance version 4.50 and 4.40. The exploit allows remote unauthenticated attackers to run arbitrary commands as the www-data user.

Unauthenticated RCE in Bricks Builder Theme

Authors: Calvin Alkan and Valentin Lobstein
Type: Exploit
Pull request: #18891 contributed by Chocapikk
Path: multi/http/wp_bricks_builder_rce
AttackerKB reference: CVE-2024-25600

Description: This PR adds an exploit module that targets a known vulnerability, CVE-2024-25600, in the WordPress Bricks Builder Theme, versions prior to 1.9.6.

Sharepoint Dynamic Proxy Generator Unauth RCE

Authors: Jang and jheysel-r7
Type: Exploit
Pull request: #18721 contributed by jheysel-r7
Path: windows/http/sharepoint_dynamic_proxy_generator_auth_bypass_rce
AttackerKB reference: CVE-2023-24955

Description: This PR adds a module that allows unauthenticated remote code execution as Administrator on Sharepoint 2019 hosts. It performs this by exploiting two vulnerabilities in Sharepoint 2019. First, it uses CVE-2023-29357, an auth bypass patched in June of 2023 to impersonate the Administrator user, then it uses CVE-2023-24955, an RCE patched in May of 2023 to execute commands as Administrator.

Enhancements and features (4)

  • #18925 from sjanusz-r7 – Updates RPC API to include Auxiliary and Exploit modules in session.compatible_modules response.
  • #18982 from ekalinichev-r7 – Adds RPC methods session.interactive_read and session.interactive_write that support interaction with SQL, SMB, and Meterpreter sessions via RPC API.
  • #19016 from zgoldman-r7 – Updates the MSSQL modules to support the GUID column type. This also improves error logging.
  • #19017 from zgoldman-r7 – Improves the auxiliary/admin/mssql/mssql_exec and auxiliary/admin/mssql/mssql_sql modules to have improved error logging.

Bugs fixed (6)

  • #18985 from cgranleese-r7 – Fixes store_valid_credential conditional logic for unix/webapp/wp_admin_shell_upload module.
  • #18992 from adfoster-r7 – Fixes a crash within the postgres version module.
  • #19006 from cgranleese-r7 – This fixes an issue where WMAP plugin module loading was causing failures.
  • #19009 from sjanusz-r7 – Updates modules/exploits/osx/local/persistence to no longer be marked as a compatible module for Windows targets.
  • #19012 from zeroSteiner – This fixes an issue that was reported where msfconsole will fail to start if the user’s /etc/hosts file contained a host name ending in a . or containing _ characters.
  • #19015 from zeroSteiner – Previously, we fixed an issue where Metasploit would crash while parsing the hosts file if it ended in unexpected values like . or _. This fixes the same kind of issue in DNS names that enter the hostnames data through a different path by removing any trailing . so they can be used for DNS resolution.

Documentation added (1)

  • #18961 from zgoldman-r7 – This adds documentation for the new SQL and SMB session types.

You can always find more documentation on our docsite at docs.metasploit.com.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate
and you can get more details on the changes since the last blog post from
GitHub:

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest.
To install fresh without using git, you can use the open-source-only Nightly Installers or the
commercial edition Metasploit Pro

A backdoor in xz

Post Syndicated from corbet original https://lwn.net/Articles/967180/

Andres Freund has posted a
detailed investigation into a backdoor that was shipped with versions
5.6.0 and 5.6.1 of the xz compression utility. It appears that the
malicious code may be aimed at allowing SSH authentication to be bypassed.

I have not yet analyzed precisely what is being checked for in the
injected code, to allow unauthorized access. Since this is running
in a pre-authentication context, it seems likely to allow some form
of access or other form of remote code execution.

The affected versions are not yet widely shipped, but checking systems for
the bad version would be a good idea.

Nexthink scales to trillions of events per day with Amazon MSK

Post Syndicated from Moe Haidar original https://aws.amazon.com/blogs/big-data/nexthink-scales-to-trillions-of-events-per-day-with-amazon-msk/

Real-time data streaming and event processing present scalability and management challenges. AWS offers a broad selection of managed real-time data streaming services to effortlessly run these workloads at any scale.

In this post, Nexthink shares how Amazon Managed Streaming for Apache Kafka (Amazon MSK) empowered them to achieve massive scale in event processing. Experiencing business hyper-growth, Nexthink migrated to AWS to overcome the scaling limitations of on-premises solutions. With Amazon MSK, Nexthink now seamlessly processes trillions of events per day, reaching over 5 GB per second of aggregated throughput.

In the following sections, Nexthink introduces their product and the need for scalability. They then highlight the challenges of their legacy on-premises application and present their transition to a cloud-centered software as a service (SaaS) architecture powered by Amazon MSK. Finally, Nexthink details the benefits achieved by adopting Amazon MSK.

Nexthink’s need to scale

Nexthink is the leader in digital employee experience (DeX). The company is shaping the future of work by providing IT leaders and C-levels with insights into employees’ daily technology experiences at the device and application level. This allows IT to evolve from reactive problem-solving to proactive optimization.

The Nexthink Infinity platform combines analytics, monitoring, automation, and more to manage the employee digital experience. By collecting device and application events, processing them in real time, and storing them, our platform analyzes data to solve problems and boost experiences for over 15 million employees across five continents.

In just 3 years, Nexthink’s business grew tenfold, and with the introduction of more real-time data our application had to scale from processing 200 MB per second to 5 GB per second and trillions of events daily. To enable this growth, we modernized our application from an on-premises single-tenant monolith to a cloud-based scalable SaaS solution powered by Amazon MSK.

The next sections detail our modernization journey, including the challenges we faced and the benefits we realized with our new cloud-centered, AWS-based architecture.

The on-premises solution and its challenges

Let’s first explore our previous on-premises solution, Nexthink V6, before examining how Amazon MSK addressed its challenges. The following diagram illustrates its architecture.

Nexthink v6

V6 was made up of two monolithic, single-tenant Java and C++ applications that were tightly coupled. The portal was a backend-for-frontend Java application, and the core engine was an in-house C++ in-memory database application that was also handling device connections, data ingestion, aggregation, and querying. By bundling all these functions together, the engine became difficult to manage and improve.

V6 also lacked scalability. Initially supporting 10,000 devices, some new tenants had over 300,000 devices. We reacted by deploying multiple V6 engines per tenant, increasing complexity and cost, hampering user experience, and delaying time to market. This also led to longer proof of concept and onboarding cycles, which hurt the business.

Furthermore, the absence of a streaming platform like Kafka created dependencies between teams through tight HTTP/gRPC coupling. Additionally, teams couldn’t access real-time events before ingestion into the database, limiting feature development. We also lacked a data buffer, risking potential data loss during outages. Such constraints impeded innovation and increased risks.

In summary, although the V6 system served its initial purpose, reinventing it with cloud-centered technologies became imperative to enhance scalability, reliability, and foster innovation by our engineering and product teams.

Transitioning to a cloud-centered architecture with Amazon MSK

To achieve our modernization goals, after thorough research and iterations, we implemented an event-driven microservices design on Amazon Elastic Kubernetes Service (Amazon EKS), using Kafka on Amazon MSK for distributed event storage and streaming.

Our transition from the v6 on-prem solution to the cloud-centered platform was phased over four iterations:

  • Phase 1 – We lifted and shifted from on premises to virtual machines in the cloud, reducing operational complexities and accelerating proof of concept cycles while transparently migrating customers.
  • Phase 2 – We extended the cloud architecture by implementing new product features with microservices and self-managed Kafka on Kubernetes. However, operating Kafka clusters ourselves proved overly difficult, leading us to Phase 3.
  • Phase 3 – We switched from self-managed Kafka to Amazon MSK, improving stability and reducing operational costs. We realized that managing Kafka wasn’t our core competency or differentiator, and the overhead was high. Amazon MSK enabled us to focus on our core application, freeing us from the burden of undifferentiated Kafka management.
  • Phase 4 – Finally, we eliminated all legacy components, completing the transition to a fully cloud-centered SaaS platform. This multi-year journey of learning and transformation took 3 years.

Today, after our successful transition, we use Amazon MSK for two key functions:

  • Real-time data ingestion and processing of trillions of daily events from over 15 million devices worldwide, as illustrated in the following figure.

Nexthink Architecture Ingestion

  • Enabling an event-driven system that decouples data producers and consumers, as depicted in the following figure.

Nexthink Architecture Event Driven

To further enhance our scalability and resilience, we adopted a cell-based architecture using the wide availability of Amazon MSK across AWS Regions. We currently operate over 10 cells, each representing an independent regional deployment of our SaaS solution. This cell-based approach minimizes the area of impact in case of issues, addresses data residency requirements, and enables horizontal scaling across AWS Regions, as illustrated in the following figure.

Nexthink Architecture Cells

Benefits of Amazon MSK

Amazon MSK has been critical in enabling our event-driven design. In this section, we outline the main benefits we gained from its adoption.

Improved data resilience

In our new architecture, data from devices is pushed directly to Kafka topics in Amazon MSK, which provides high availability and resilience. This makes sure that events can be safely received and stored at any time. Our services consuming this data inherit the same resilience from Amazon MSK. If our backend ingestion services face disruptions, no event is lost, because Kafka retains all published messages. When our services resume, they seamlessly continue processing from where they left off, thanks to Kafka’s producer semantics, which allow processing messages exactly-once, at-least-once, or at-most-once based on application needs.

Amazon MSK enables us to tailor the data retention duration to our specific requirements, ranging from seconds to unlimited duration. This flexibility grants uninterrupted data availability to our application, which wasn’t possible with our previous architecture. Furthermore, to safeguard data integrity in the event of processing errors or corruption, Kafka enabled us to implement a data replay mechanism, ensuring data consistency and reliability.

Organizational scaling

By adopting an event-driven architecture with Amazon MSK, we decomposed our monolithic application into loosely coupled, stateless microservices communicating asynchronously via Kafka topics. This approach enabled our engineering organization to scale rapidly from just 4–5 teams in 2019 to over 40 teams and approximately 350 engineers today.

The loose coupling between event publishers and subscribers empowered teams to focus on distinct domains, such as data ingestion, identification services, and data lakes. Teams could develop solutions independently within their domains, communicating through Kafka topics without tight coupling. This architecture accelerated feature development by minimizing the risk of new features impacting existing ones. Teams could efficiently consume events published by others, offering new capabilities more rapidly while reducing cross-team dependencies.

The following figure illustrates the seamless workflow of adding new domains to our system.

Adding domains

Furthermore, the event-driven design allowed teams to build stateless services that could seamlessly auto scale based on MSK metrics like messages per second. This event-driven scalability eliminated the need for extensive capacity planning and manual scaling efforts, freeing up development time.

By using an event-driven microservices architecture on Amazon MSK, we achieved organizational agility, enhanced scalability, and accelerated innovation while minimizing operational overhead.

Seamless infrastructure scaling

Nexthink’s business grew tenfold in 3 years, and many new capabilities were added to the product, leading to a substantial increase in traffic from 200 MB per second to 5 GB per second. This exponential data growth was enabled by the robust scalability of Amazon MSK. Achieving such scale with an on-premises solution would have been challenging and expensive, if not infeasible.

Attempting to self-manage Kafka imposed unnecessary operational overhead without providing business value. Running it with just 5% of today’s traffic was already complex and required two engineers. At today’s volumes, we estimated needing 6–10 dedicated staff, increasing costs and diverting resources away from core priorities.

Real-time capabilities

By channeling all our data through Amazon MSK, we enabled real-time processing of events. This unlocked capabilities like real-time alerts, event-driven triggers, and webhooks that were previously unattainable. As such, Amazon MSK was instrumental in facilitating our event-driven architecture and powering impactful innovations.

Secure data access

Transitioning to our new architecture, we met our security and data integrity goals. With Kafka ACLs, we enforced strict access controls, allowing consumers and producers to only interact with authorized topics. We based these granular data access controls on criteria like data type, domain, and team.

To securely scale decentralized management of topics, we introduced proprietary Kubernetes Custom Resource Definitions (CRDs). These CRDs enabled teams to independently manage their own topics, settings, and ACLs without compromising security.

Amazon MSK encryption made sure that the data remained encrypted at rest and in transit. We also introduced a Bring Your Own Key (BYOK) option, allowing application-level encryption with customer keys for all single-tenant and multi-tenant topics.

Enhanced observability

Amazon MSK gave us great visibility into our data flows. The out-of-the-box Amazon CloudWatch metrics let us see the amount and types of data flowing through each topic and cluster. This helped us quantify the usage of our product features by tracking data volumes at the topic level. The Amazon MSK operational metrics enabled effortless monitoring and right-sizing of clusters and brokers. Overall, the rich observability of Amazon MSK facilitated data-driven decisions about architecture and product features.

Conclusion

Nexthink’s journey from an on-premises monolith to a cloud SaaS was streamlined by using Amazon MSK, a fully managed Kafka service. Amazon MSK allowed us to scale seamlessly while benefiting from enterprise-grade reliability and security. By offloading Kafka management to AWS, we could stay focused on our core business and innovate faster.

Going forward, we plan to further improve performance, costs, and scalability by adopting Amazon MSK capabilities such as tiered storage and AWS Graviton-based EC2 instance types.

We are also working closely with the Amazon MSK team to prepare for upcoming service features. Rapidly adopting new capabilities will help us remain at the forefront of innovation while continuing to grow our business.

To learn more about how Nexthink uses AWS to serve its global customer base, explore the Nexthink on AWS case study. Additionally, discover other customer success stories with Amazon MSK by visiting the Amazon MSK blog category.

About the Authors

Moe HaidarMoe Haidar is a principal engineer and special projects lead @ CTO office of Nexthink. He has been involved with AWS since 2018 and is a key contributor to the cloud transformation of the Nexthink platform to AWS. His focus is on product and technology incubation and architecture, but he also loves doing hands-on activities to keep his knowledge of technologies sharp and up to date. He still contributes heavily to the code base and loves to tackle complex problems.
Simone PomataSimone Pomata is Senior Solutions Architect at AWS. He has worked enthusiastically in the tech industry for more than 10 years. At AWS, he helps customers succeed in building new technologies every day.
Magdalena GargasMagdalena Gargas is a Solutions Architect passionate about technology and solving customer challenges. At AWS, she works mostly with software companies, helping them innovate in the cloud. She participates in industry events, sharing insights and contributing to the advancement of the containerization field.

The collective thoughts of the interwebz