>> Good news we're back with another episode of
Armchair Architects, the Azure Enablement Series. That's an ongoing
conversation with Eric and Woolley two of the
smartest architects I know. This episode, we're going to dig
into something super interesting. We're going to talk about
the relationship between simplicity and
architecture so join us. [MUSIC]. >> Hey, so welcome back
to another episode of Armchair Architects as part
of the Azure Enablement Show. In the last topic, we were talking a little bit
about how to become an architect, and the thing that kept
on coming up for us was questions around
simplicity and complexity, and I would really love to dive
in with my colleagues here, Uli and Eric, into that question. If you folks are up for it, I want to start to dive into
the role of simplicity in architecture because I suspect it's really fun to toss off things like I'll make it as
simple as possible, but no simpler, and
drop the mic and walk away but I suspect
there's more to it. Can we talk a little
bit about simplicity? Is that your primary goal? Is that a secondary goal when
you're designing architectures? Is that not a goal at all, what's the role of simplicity when you're architecting
like your architect? >> I think to me, it's more of a philosophy or a
pervasive thread that you often have to revisit at
every stage when you're asking, as Woolley said before,
the why questions. If you're like me from an
architecture perspective, you're visualizing the way that these solutions
might fit together, and then you're asking yourself whether it's in your brain
or if it's on paper, or in your favorite
architecture diagramming tool. It is this as simple as it needs to be or is it overly complex
and can I reduce it further? Am I providing too many knobs
and bells and whistles? Can I create a more coarse-grained
API interface across my microservice
architecture and that way I can actually make it easier on the
people that have to consume it? To me, it's something
that you visit and revisit critically all throughout
the architect journey. >> I would add to this and David, you will appreciate this
being an operations person. Simplicity is a question that you should ask from
multiple dimensions. Eric mentioned the developer pieces in terms of technical simplicity, of course, grained access versus fine-grained
access, and so forth. I also look at and have the
notion of what happens if stuff breaks at 3 AM in the morning and the developer isn't available
to debate the code. How do you tell an operations
person how to deal with the system, and the more complex the system is, the more hard it is to
effectively go and bring it back online or make sure
that the customers can successfully complete the
operations, and so for me, simplicity also has to
do with, stuff bricks, what happens and then the last
piece of that which goes in the similar vein is if I have to update the solution,
how do I do this? How many things to have
to touch to update the capabilities that I'm building out and the more things
I have to touch, the more complex it
is, and therefore, the likelihood of failure is much
higher than if I keep it simple. >> I remember one of my favorite talks was
given by Casey Rosenthal, in which he was discussing the
notion of necessary complexity. You're saying, okay, cool, I build something and
it runs on my laptop. That's cool but that's
not really what you need. You need to put it on
somewhere else, and really, if you want to make sure
that it doesn't fall over, you want two of them, and so, making redundancy has unnecessary
complexity cost to it whereas, if you'd like it's
simpler but we all agree that two of them
is better than one but I also have not met an architect
who doesn't recognize that, going from one to two is a really big leap
sometimes when it comes to architectures or one to five, is even bigger, but one to two job. Is there a way of because
the thing that's tricky about this is when you're talking about features the
thing that's tricky here is, is it possible to retain simplicity even though the incentives
are to add features? How do you do that? >> I think it's a
scale or a spectrum, almost an imaginary
slider, and in one way, if you slide it into the
more I'll call it the fine-grained approach higher
technical complexity, but more control for consumers of that particular service or
application over capability. If you slide it the other way, you get probably a much
better user experience that's more tightly integrated, but you give up some of that
exposed control capabilities, and it's the things that many developers might
want so if you're an ISV, you probably do want
to think about what your API surface is
going to look like for consumers of that
particular service. Also, I would advise that
you have to think about the way in which your
consumers, your customers, or your organization will consume your components think about what
code they will have to write that you're forcing them to write
based on the API surface and the other solution
architecture that you're building versus the code
that they want to write. In other words, is your
API a delight to consume, or is it really tough because
you have to spend a ton of time stitching together
solution components, utilizing surgical code, and making the integration really
difficult and not consumable? >> What do you mean
by surgical code? I just want to stop you right there. What does surgical code mean? I've not heard that term before. >> To me, a surgical
code is any type of integration between
components that require a significant
amount of wiring up of those components so that
they can talk to each other. Everything related to identity
and access management to course green or find green
API service capabilities. The more powerful I guess an
individual components API is, the more you're going
to have to do to get that API to talk to another
API or talk to your service. >> I guess but I'm still
stuck on this notion that says everybody wants more
features, everybody wants it, the next revision to be
whatever in its work that it didn't have prior very seldom are
people done everything's cool. How do you deal with
that not done and yet not more complex
every step of the way, because otherwise, it seems to imply that the world
tends towards complexity, and is that true? Is that an existential truth that I should just
get over right now? >> No more functionality does not automatically
mean more complexity. It means more surface
area potentially from an API perspective
like Eric talked about but if you are
providing a consistent model, so let's define what
is an API these days. On the one side, you have a rest interface that
most likely follows open API standards from a shape perspective and
exposure perspective. What used to be called swagger, that's now called Open API, and that's certainly one API surface that you want to think
about, and again, more APIs means a little
bit more complexity but because the API follows a certain standard open API,
it's fairly straightforward. As a user of this API will
be able to go and say, that's another capability that
I have that these guys now provide but because it's the same API shape, it's
fairly straightforward. The second type of
API that's becoming, I think standard as well
is event-based exposure. You effectively have a reactive, which is the risk-based API, and a proactive or
observable API where the system raises an API call through technologies like
Azure Event Grid or similar, and effectively somebody then says, I'm interested in that
event, and again, that's just more event surface, but the consumption is
structured and simple. From that perspective, yes, it's more complicated
because it's richer, but it's not more complicated because the consumption is
straightforward and easy. If you would say, hey, I have APIs, I have a event, and the APIs have
different structure. You would use let's say, instead of rest-based
APIs only you also throw in some older technologies
like soap and just throw some other stuff
in where instead of you using consistently JSON and
those things you throw in, this has XML, this is JSON, this is a CVS file
then gets complicated. For me, consistency is one
part of the art of simplicity. >> I'm thinking back to
our last discussion, which we were talking about
how to become an architect, and it made me think about how we talk about
simplicity and complexity. Obviously, it's not binary. This is not either
simple or complex. But do we have the right words? Like when you walk into a room
and you want to tell somebody, gosh, that seems complex, do we have any terms
or ways of talking about this is more or less complex
besides more or less complex? Are there ways to say that in a slightly less subjective manner
when we say how complex it is? How do you describe complexity
is what I'm asking? >> Yeah. One thing that we are really pushing hard on right now in the Azure world is concept count. How many concepts do you as a person that's
participating in the technology, or is trying to use the technology, have to understand in
order for you to use it? If the concept count goes over five, most people are opting out
because it's too complicated. Ideally, you have one major concept, maybe two or three, but that's about it, and most people just don't have
the patience or the time to really understand five or more
concepts in a single solution. For me, complexity is almost
linear with concepts counts. Effectively how many concepts
do you have in that solution? If it's too much, it's
getting too hard. >> What's an example of a concept? I want to hear what
you have to say, Eric, but I just want to make
sure that I'm clear on what's an example of a concept? >> I already talked
about two concepts. On the one side you have an API, and the other said
you have an event. >> I see. Great. >> Those kind of things,
those are concepts. But then you throw in, let's say if you are like Eric, in the IoT world, you throw in, there's a device
that you have to think about. That's a necessary concept
and important concept in IoT. But now you have three,
that's still okay. But how many more can you add before
the solution gets too complex for people to really grasp and put their head around and
use it consistently, which is really what you want? For me, concept count below five is an important simplicity element. >> The term I've heard
used is cognitive load, but concept count
sounds really close. Well, it looks like
you wanted to say something Eric and I cut you off, because I just wanted
to get some clarity. >> No, these are all great points. A couple of random
thoughts that I think really apply here are like I think
of architecture like fractions. Your goal is to reduce them to
the lowest common denominator. Whether looking at it in
terms of concept counts or going back to that nagging
feeling of is this simple enough. The way to do this to justify it as well is that you can't
just go out and say, this is my simple architecture, I've solved it, stamped
it, and it's done. In many instances,
you have to actually show other architects that
you've completed the thought. In many cases you'll actually
have to be like, well, I considered this approach and these other approaches
and these opponents, but I rejected them
based on these concepts, and the rejection is that I
deliberately chose not to engage with these other alternatives
because I was focused on simplicity or integration of design. Or maybe I went more complex, but there was a really good
reason why I did that. The other thing I'll say is
we oftentimes, as architects, begin to think that
we're the only person around that can solve this problem, and as a result, we have
to create something new. Even things that
I've created before. This is new, this is fun. This is something I can create. Reusing things is the hallmark
of a great architect. Looking around and
saying what's been done. Whether it's the well architected
framework on our side or others or something that you've done or
a colleague of yours have done, beginning the conversation with
what patterns, what paradigms, what architectures exist that
I can reuse before I invent, I think is something
that's important. >> That's a really
important point, Eric, because there's another dimension
on simplicity versus complexity. We always assume that solutions
get built and then it's done. That is obviously not true. We have solutions that are running
on mainframes since 30 years, and they still get
maintained. They get updated. You have code bases on Windows that are 20 years old and
they get updated. Being able to update a solution, not just from a components
perspective that you depend on, but your own code, requires you to also be
not necessarily simple, but keep it as simple
as you possibly can because you might not be around
to explain what was going on. You might have moved on from
the company or the solution, and so some other person has to
now go in and understand, oh, this is what this person
meant when he designed or she designed this
capability and so forth. For me, operational perspective
and maintenance perspectives are something that are often overlooked by people that just
design and build solutions, because sometimes they're not
around when things go haywire or things have to move forward with
new capability and so forth. For me, that's another set of aspects I would throw
into this conversation. >> Well, this is one
of the reasons why I initially had some questions about the term well
architected framework, because often when you think
of architect, you think, oh, I heard an architect,
they told me how to build the thing and they designed
the thing, they built it, and then they walked away because you don't have the architect
knocking at your door going, hey, would you like to
architect some more? The conclusion I came to is, is that the key thing is staying
in a well architected state. That's one of the things
that architects can do, is they can keep you
in that state because for very many reasons that we won't go into.
But let's pretty go on. You can drop out of that state
of feeling well architected, and it's interesting to
me to hear you discuss architectural not only
as building things, but also like they might walk
into a room and help you simplify what you're seeing on the whiteboard
that already exists, and that sounds really cool. One of the things that
Uli said a moment ago was about operations and was this question about trying
to keep things running, which segues us nicely into something else that I know we
want to talk to you about, which is what to do in the
situations where you've got architectures and applications and services that have to be
running all the time, and that's a really tricky question. As per usual, I have
to ask you to like, don't you think we
should talk about that? Should we do that next? >> I think that's a great idea. >> Cool. Well, then with that, I want to thank all
you for watching us. I'm hoping you'll join us for
the next episode, which now, you know is going to be about with the Armchair Architects as part
of the Azure Enablement Show. [MUSIC]
