Full Abstract By now, just about every organization has at least a phalanx or two in the “Cloud” and it is, understandably changing the way we architect our systems. But there is a lot of confusion around cloud native, 12 factors, modular monoliths, serverless…how does a busy technologist make sense of it all? Despite what you may have read on the Internet, there still are no silver bullets - just a set of tools that we need to apply at the right time in the right place.
Full Abstract Today our world is full of things that are “as a service” - infrastructure, containers, platforms, software…and of course functions. With developers just now wrapping their heads around application platforms and containers, what are they to make of functions as a service? How does a busy developer cut through the hype and make sense of the world of serverless, Kubernetes, Spring Cloud Function and all the rest? This talk will clear up the confusion!
Full Abstract Development teams often focus on getting code to production losing site of what comes after the design and build phase. But we must consider the full life cycle of our systems from inception to deployment through to sunset, a discipline many companies refer to as site reliability engineering.
While your organization may or may not have an SRE team, you have someone playing that role and we can all benefit from looking at the principles and practices that we can bring to bear on our projects.
Full Abstract By now I bet your company has hundreds, maybe thousands of services, heck you might even consider some of them micro is stature! And while many organizations have plowed headlong down this particular architectural path, your spidey sense might be tingling…how do we keep this ecosystem healthy?
In this talk, I will go beyond the buzzwords into the nitty gritty of actually succeeding with a service based architecture.
Full Abstract If you’ve spent any amount of time in the software field, you’ve undoubtably found yourself in a (potentially heated) discussion about the merits of one technology, language or framework versus another. And while you may have enjoyed the technical debate, as software professionals, we owe it to our customers (as well as our future selves) to make good decisions when it comes to picking one technology over another.
Full Abstract Rich Hickey once said programmers know the benefits of everything and the trade offs of nothing…an approach that can lead a project down a path of frustrated developers and unhappy customers. As architects though, we must consider the trade offs of every new library, language, pattern or approach and quickly make decisions often with incomplete information. How should we think about the inevitable technology choices we have to make on a project?