If you have ever gone browsing for some great conferences for software engineers, you likely have come across No Fluff Just Stuff, aka NFJS. NFJS offers a network of conferences and webinar topics, both big and small concentrating on anything software developer and architecture focused. They offer content weekly in the form of both free webinars and full-day workshops across a variety of topics. Content is delivered by experienced architects and engineers with first-hand expertise in the topical area. Larger conferences also materialize multiple times a year with ArchConf and UberConf, which offer a mostly vendor-free experience with in-depth 90-minute sessions.
I was able to first attend ArchConf in 2019 and immediately fell in love with the longer sessions that allow you to dive deeper and get beyond some of the surface-level content. Each day is jam-packed full from early morning to well after dinner in the evening in a very accessible location where you are not walking 20 min to your next session.
Earlier this year I had the fantastic opportunity to join the schedule with some of the NFJS tour stops and represent SPS Commerce with some of our latest development and patterns and practices. The opportunity to share with the external community as well as learn from the audience and engage with engineers across the industry is incredibly valuable.
The first stop was an NFJS Free Webinar that took place on May 6, 2022, remotely. The webinars are zoom-based and allow for great bi-directional discussion. Had some great questions early on and good engagement throughout the hour. Feel free to catch the recording if you are interested: Amp Up Deploy Velocity with Feature Flags.
Coming up, you can also find me in person, representing SPS Commerce, with further topics at UberConf and ArchConf.
Sharing code and internal libraries across your distributed microservice ecosystem feels like a recipe for disaster! After all, you have always been told and likely witnessed how this type of coupling can add a lot of friction to a world that is built for high velocity. But I’m also willing to bet you have experienced the opposite side effects of dealing with dozens of services that have had the same chunks of code copied and pasted over and over again, and now you need to make a standardized, simple header change to all services across your platform; talk about tedious, frictional, error-prone work that you probably will not do! Using a variety of code-sharing processes and techniques like inner sourcing, module design, automated updates, and service templates, reusing code in your organization can be built as an asset rather than a liability.
In this talk, we will explore the architectural myth in microservices that you should NEVER share any code and explore the dos and don’ts of the types of reuse that you want to achieve through appropriate coupling. We will examine effective reuse patterns, including what a Service Template architecture looks like, while also spending time on the lifecycle of shared code and practically rolling it out to your services. We will finish it off with some considerations and struggles you are likely to run into introducing code reuse patterns into the enterprise.
Modern HTTP APIs practically run the contemporary tech world. The number of APIs your organization is actively building and maintaining is evidence of that, and you need no convincing of the value of API Design First principles. However, introducing an API Design First process and methodologies can be fraught with too much manual effort, slow progress, inconsistencies, and further chaos as you’re organization scales. Much of this friction can be alleviated by developing a mature API Design First process within the organization that is supported by first-class tooling and the use of automation.
In this talk, we will dive into the principle areas of API Design First across its lifecycle as we discuss how to accelerate value in design, development, governance, documentation, and change. Whether you already have established API Design First methodologies or are considering how to effectively adopt it, you should leave with a practical understanding of effective processes and governance. Experience how SPS Commerce thinks about API Design First with a strong preference towards governance through collaboration along with examples of key processes that simply must be automated to succeed in an API-First world.
A lot of development teams have built out fully automated CI/CD pipelines to deliver code to production fast! Then you quickly discover that the new bottleneck in delivering features is their existence in long-lived feature branches and no true CI is actually happening. This problem compounds as you start spinning up microservices and building features across your multi-repo architecture and coordinating some ultra-fancy release schedule so it all deploys together. Feature flags provide you the mechanism to reclaim control of the release of your features and get back to short-lived branches with true CI. However, what you’re not told about feature flags in those simple “if/else” getting started demos is that there is an upfront cost to your development time, additional complexities, and some pitfalls to be careful of as you begin expanding feature flag usage to the organization. If you know how to navigate these complexities you will start to unleash true velocity across your teams.
In this talk, we’ll get started with some of the feature flagging basics before quickly moving into some practical feature flagging examples that demonstrate its usage beyond the basic scenarios as we talk about UI, API, operations, migrations, and experimentation. We will explore some of the hard questions around “architecting feature flags” for your organization.
[…] No Fluff Just Stuff was at the top of my ranked list, as I’m a big fan of their smaller conference style, long sessions, and jampacked content from industry experts. It was one of my goals to speak at ArchConf, knowing the level of quality presenters and attendees. I had the opportunity to do this at the end of 2022. […]