Dev Week 2023 experience from a Solutions Engineer perspective
- Published on
As an Enterprise Solutions Engineer, I see large enterprises tackling operational challenges from a variety of angles and industries. This gives me an interesting perspective when learning about new technology trends and the challenges that they solve. This year, I went to Developer Week in Oakland, CA to see where the tech industry was going from the eyes of developers. There were sessions all day for 3 days at multiple different stages, so tons of content, but I saw some common themes including security, MLOps, data management, and application optimization. Unfortunately, I wasn’t able to see all the sessions live, but I’m hoping to catch the recordings of the sessions I missed and add more details to this blog then. I’ll highlight my top 3 live sessions that I saw and highlight 3 other talks that I wish I went to and why I will be making sure to watch their recordings.
The best session I saw was on a new technology called WebAssembly. As we’ve seen before in virtualization technology, The compute slices have gotten smaller, more efficient, more scalable and more flexible like the transitions from physical servers to VMs and then VMs to containers. WebAssembly is the next step in this journey due to the difficulty of running containers in a serverless environment. According the CEO of Fermyon, Matt Butcher, containers take too long to start up (seconds), which won’t work when executing serverless functions. WebAssembly solves this by providing subms startup time and allowing code to be run anywhere, which has been a challenge for container implementation because containers need to be built and run on a specific OS. If you want to see this technology in action, Finicky Whiskers is built on WebAssembly microservices. If you want to try to build an application on top of WebAssembly microservices, you can use Fermyon Cloud to play around with this new technology.
Another great presentation was from Jaxon Repp, Field CTO at HarperDB. Jaxon talked about the current challenges of using cloud-native database solutions at scale and the dynamic, complex application architectures that are so painful. He dove into the architecture behind this database and the story of how the team made their decisions and what worked and what didn’t. The team combined the flexibility and ease of use of JavaScript for front-end development and the open-source LMDB Storage engine for speed and simplicity for back-end transactions. The 3 features that really stood out to me were: Attribute-level role-based access control, custom functions, and their database mesh. Attribute-level role-based access control (ABAC) expands on Role Based Access Control (RBAC) by allowing admins to control access using multiple attributes at a time, automatically updating access control policies based on time of day, user location, etc., and staying compliant, scaling to a large number of users and automating policies easily. HarperDB also makes it easy to customize complex data processing tasks and custom business logic using custom functions that can be written in JavaScript or Python and can be stored in the database for future use or reuse across applications or projects. In order to scale applications globally while maintaining high performance, HarperDB uses a database mesh called clustering with user-defined, table-level replication patterns in a pub/sub model, which optimizes storage and bandwidth.
The last session I’ll talk about in this blog was delivered by Dave McAllister, a OSS Technical Evangelist from NGINX, where he explained some challenges and solutions of modern day observability. The main challenge he talks about is how to monitor microservice-based architectures which are ephemeral, constantly changing, and produces tons of observability data with all the components needed for this type of architecture. Observability, as Dave said, relies on metrics, traces, and logs for finding problems (detection), location of problems (troubleshooting) and reasons why the problem is happening (Root cause analysis). To start, you have to filter the data coming in, sample the data, and visualize the data. This is much easier said than done considering concerns like, what are you filtering by?; how do you choose what to sample?; and how do you see issues like memory leaks that happen outside of the components of your application, but still affect it?. Dave brought up a ton of thought provoking questions that really make you think and ends it by suggesting that observability tools need to adapt to capture events accurately and optimize capacity for observability data.
These sessions taught me a ton about where the industry is headed and inspired me to want to dive into distributed databases specifically. With serverless functions playing a major role, being able to ingest data quickly all across the globe becomes a business critical function. I’ll look forward to learning more and sharing what I learned on this platform. Some future sessions that I’ll be watching and sharing are “Distributed SQL: The NEW Way of Scaling Large Databases” by Kathryn Sizemore from MariaDB, and “Automating Security for Serverless Applications” by Steve Wilson from Contrast Security.
Markdown is a lightweight markup language that you can use to add formatting elements to plaintext text documents. Using Markdown is different than using a WYSIWYG editor. In an application like Microsoft Word, you click buttons to format words and phrases, and the changes are visible immediately. Markdown isn’t like that. When you create a Markdown-formatted file, you add Markdown syntax to the text to indicate which words and phrases should look different.