Transcription
Audience: [Applause]
Phil Hawksworth: Thank you very much, Marc. Thank you for a loving introduction. Hello.
Audience: Hello.
Phil Hawksworth: Oh, there are people there. I’m very happy that you came back from lunch. That’s a good start. I’m conscious that this is a dark room, we’ve all got full bellies, and my voice can get quite deep.
Audience: [Laughter]
Phil Hawksworth: And if you feel yourself nodding off, I will be offended, but let’s see if we can stop that from happening. I don’t know. Mine might not be the most visual and beautiful talk of the day, but let’s see if we can power through this graveyard shit shift.
Hello. My name is Phil Hawksworth, as Marc--wherever he went--quite rightly said. I don’t know about you. Actually, I could just listen to Toby all day. I don’t know.
Audience: [Applause]
Phil Hawksworth: Yeah. Amazing. Newsflash: you can’t because I’m here now. So sorry. Sorry to stand in the way of that, but yeah, so my name is Phil Hawksworth. I’m a technology director working at an agency in London called R/GA.
I usually say in talks like this that I’ll take questions on Twitter, and you can always fire questions, comments, anything you like at me. My Twitter name is just my name, so it’s at least easy for me to remember.
But also, I’ll be around. So if you have questions, you want to grab me and talk about anything, or say I’m an idiot and you disagreed, that’s fine. Come and do that.
Let me introduce very quickly who R/GA are. R/GA makes stuff for clients.
Audience: [Laughter]
Audience member: Whoo.
Phil Hawksworth: Yeah. Whoo! There was a whoo for that. Low standards over there. That’s nice.
Audience: [Laughter]
Phil Hawksworth: That’s good news for me. I mean that’s how I describe it because it’s really broad the way that R/GA, when they see this, will tell me in the future to describe it, is R/GA creates products, services, and communications that help grow our clients’ businesses. It sounds an awful lot like an agency, and I think actually this is a useful description because everything is so broad that we do. We’ll build Web applications, websites, mobile applications, physical devices, communications, TV adverts, all kinds of things.
Me, personally, I come from a Web background. I make stuff for the Web. That’s the things I really care most about and what’s kind of the motivation for here, for my talk here. My position is there that I’m a technology director, which means that more often than not--
Audience: [Laughter]
Phil Hawksworth: --I’m the dream crusher. I am the crusher of the dreams. I’ll be honest. That little sound byte, I only said that because I’m hoping -- yeah, please.
Audience: [Laughter]
Phil Hawksworth: This is a sound byte driven talk.
Audience: [Laughter]
Phil Hawksworth: The content is entirely motivated, but I hope that’s okay. But yeah, so in all seriousness, I have earned this nickname a few times over the years, which is not anyone’s real dream, so to speak, you know, anyone’s ambition to become the dream crusher on projects. But often if you are the technologist in the room on a project, sometimes you have to come in with a dose of reality. That’s just the way it is. Our ambitions sometimes outreach what we can actually achieve.
This cartoon, this kind of looks like Sam Blaster (phonetic), I’ve just realized, at the bottom whose dream I’m crushing. Sam, I’m sorry. Sam is around somewhere. It’s not Sam. It’s my friend Steve, who is an illustrator and designer I’ve worked with over the years. Steve felt compelled to make this cartoon because he feels so strongly about the fact that I would come and trample on his dreams from time-to-time. He felt so strongly, in fact, that he did a whole brand identity for me.
Audience: [Laughter]
Phil Hawksworth: I don’t know. There’s a T-shirt in there, I think, somewhere. But he also even rendered me as a super villain who would swoop in and really ruin his ambitions. I show this because this is something obviously I want to do away with. That’s not -- no one has the ambition of being someone who ruins the fun and stops people achieving the right things.
And I kind of show this because I kind of want to give a bit of context to where I’ve come from. I’ve done a handful of different talks in the past, but they all kind of follow this similar theme where I seem to be the dream crusher from time-to-time. My first talk, as Marc pointed out, actually at Full Frontal in Brighton, was this talk called Excessive Enhancements, and it was about doing things responsibly and being careful what we make.
It kind of went on to another talk, which is about the pain that is inherent in content management systems and how often that will kind of bleed through into the code. As Web developers, you know, we want to keep pristine and do nicely, so I kind of grumbled about it in a talk like that.
Then I kind of was positioning that actually if you simplify things and simplify this stuff, you can do better, and so that led me on to talks about static site strategies and those kind of things. I’ll share the links to these later. I won’t leave them on the screen for long. These slides will be available later, but you can see the background in those.
It seems a bit self-serving, but the reason I’m kind of talking about that is because there has been this progression. This first talk was all about saying we need to take care in what we send down the wire to the browser and do things carefully. Take care of the Web.
The next one is saying, well, you know, big concept management systems could mess up what you do sent to the browser and what strategies are there for simplifying things so that we can do things the right way and send the right things down the wire to the browser? Then kind of building on that, then, well, actually, no, this new -- well, there’s old strategy actually to make things static, and that could maybe go much further than we were expecting and give back a little bit of control. But that kind of runs into kind of limitations, so that’s where I’m trying to go at the moment.
I’m thinking beyond these kind of static sites that I’m always banging on about. If you do talk to me in the bar later on, I will bend your ear about that. There are limitations on what we do to go past it.
But this theme that runs throughout all of this, ultimately it comes down to something I care deeply about, and that is about empowerment for front end developers. In fact, well, empowerment and responsibility for all developers. I think we care very deeply about the craft of what we make and how we make it. It’s hugely frustrating when tools and processes get in the way and kind of stop us being able to do that.
Something I’m always fighting for is this opportunity to making things simple. That’s a dangerous expression. You know the word “simple” on there is a very easy one to bandy about, and we need to be a little bit careful about it. I think maybe a better way to phrase this would be making things less complex.
Sharon, earlier on, gave a fantastic talk where she talked about empowering people and about empathy. There are lots of different ways to empower people and lots of different ways to, you know, hinder people. I think complexity can be a barrier. It can be a huge barrier.
Conversely, simplicity can be an enabler. When we think about what we want to make, how we want to bring things to life, I’m all for simplicity.
That brings me to this talk, to Dodging Bullets, which by the way I saw the poster for outside and I absolutely love. I didn’t realize I was going to get film branding, so I thought long and hard about this title. The first thing, obviously, I wanted to do was make sure I had the longest title in the running order because that way it would take up the most space and make me look much more important.
Audience: [Laughter]
Phil Hawksworth: But you know Dodging Bullets. Microservices for Fewer Sleepless Nights, that doesn’t seem to mean very much, and so I’m rethinking about, how do we use other people’s infrastructure with these microservices? How can we do that?
I started playing with Other People’s Plumbing, and that’s just a horrible expression: other people’s plumbing.
Audience: [Laughter]
Phil Hawksworth: Not very personal at all, so I moved on from there quite quickly. Functions as a Service because, yeah, that’s kind of what we’re talking about a little bit here. Functions as a Service: FAAS for Fewer Sleepless Nights, which of course brought me immediately to The FAAS and the Furious.
Audience: [Laughter]
Phil Hawksworth: No, really. This is the direction we’re going. By the way, how lovely is it that Vin Diesel gets a lovely little tiara out of that?
Audience: [Laughter]
Phil Hawksworth: That’s just a delightful side effect. But this is working out quite well for me already because this is my first time at Beyond Tellerrand. This is a wonderful event, and I’m determined to come back again and again. This title affords me the opportunity to come back year after year after year.
Audience: [Laughter]
Phil Hawksworth: How many are there in this franchise? There are dozens of them.
Audience: [Laughter]
Phil Hawksworth: I don’t know. It feels like I can squeeze enough out of this title, even if you’ve all gone home in--I don’t know--2030 by the time I’ve finished doing this.
Anyhoo, all of this comes back to the point of, what are we talking about? I’ve been building things for the Web for a long time. Once upon a time life was simple. A website was a collection of static things. We had files. We put them on a Web server, and a Web server did a great job of distributing that to whoever came along to look at that.
But if we unpack things a little bit more and see how a website works now, it’s a little bit different to that. We’ve probably got some views that we render. Those are probably determined by some kind of routing that happens depending on the URL that we’ve hit. Those roots will probably populate the templates based on some kind of application logic, which might be digging into some kind of database or some content store or something else.
We’ll probably put some kind of caching in front of that so it goes fast. We’ll wrap it all up in some kind of a server. Chances are we’ll have several servers so that we’ve got redundancy and we can do things like load balancing and keep the lights turned on. There may be other systems that this integrates with.
There might be some content management system somewhere that could be on the same servers. It could be somewhere else. There might be a digital asset management system that has all of your images, your assets, your other resources that you need to include as well. That might live somewhere else in a completely different infrastructure.
Then there might be other services. There might be pricing services, tax services, fulfillment. There might be e-commerce. There might be all kinds of things that live somewhere else that you need to talk to.
We might have external logging systems. This is by no means a specification and lots of things that you would change about that. But what I’m trying to illustrate is there are lots of moving parts. To be able to do a good job of this now, you need to have a lot of skills. You need to do a lot of things at the same time.
Audience: [Laughter]
Phil Hawksworth: Realistically, you’re not going to find any one person who is going to do all of this. We talk about full stack developers, but with this kind of complexity can everyone be an expert, anyone be an expert at all of these things?
You’re going to end up probably with a big team of lots of people who have got lots of skills that they’ll need to bring to bear. By the way, if you want a sleepless night, Google for one-man-band and just drift through the images that come back. It’s heroing.
But yeah, so you find yourself with lots of people who have lots of different skills that they need. There’s a lot of complexity at work here. So if I’m really trying to chase for making things simple, I’ve recently been going static. This is not new. As I mentioned at the very beginning, it used to be simpler.
In fact, Aaron Swartz once kind of popularized this term, “Bake. Don’t fry,” when he was talking about not serving up responses to request on a Web server dynamically and on demand, but actually pre-baking things ahead of time so you can distribute them. He was coming from a similar place to where I find myself. He said, “I care about not having to maintain cranky AOL server, Postgres and Oracle Installs.” This is back in 2002, so not new, but certainly something that chimes with me. I can recognize that.
I’ve been doing lots of work recently with static sites to kind of real this in and bring some power back to what I’ve been doing. But static sites, they’re limited. They have a ceiling. But the news is that that ceiling is far higher than you might think. You can do a great deal more than you might expect.
This kind of term of static sites isn’t very sexy. It feels limited. And so when people come across this term, this is a more popular term now. People are talking about the JAMstack. I just realized I did another sound byte: the JAMstack.
Audience: [Laughter]
Phil Hawksworth: He’ll get there. He’ll get there. But, yeah, the JAMstack is this term. It’s describing JavaScript, APIs, and Markup. Really, it’s intended as another way of describing a static architecture. It’s popularized by this guy, Mathias Biilmann, who is one of the founders of Netlify, and they produce static hosting, so of course they’re invested in making that seem more appealing and seem more capable.
But you often come up against this kind of idea that there are lots of things that you just can’t do with that kind of infrastructure. You can’t, for instance, have site search. Well, actually it turns out you can. There are quite a few techniques that you come to that allow you to do dynamically searching the site of your content without a dynamic backend. You can do it with JavaScript. You can do it as a progressive enhancement and use other services to make it happen. Actually, yes, you can.
You can’t have forms on a static site. Well, again, actually, yeah, that can be fine too. If you work in the right environment, you can find small services that will provide an endpoint for you to post to, so you can actually bring that into the infrastructure as well, bring that to the capabilities of a static site.
If you can’t have forms, of course you can’t have comments. Well, once again, actually, yeah, that’s okay. You can do that. In fact, there are some really nice workflows for creating comments, having comments on what would otherwise be thought of as a static site.
Of course you can’t have content management on a static site. Well, yes, and don’t get me started on that. You absolutely can.
A lot of these things have been brought to bear by the kind of tools that surround these kind of approaches. I’ve mentioned Netlify already with Mathias, but Netlify really is this static hosting infrastructure that has other services around it. It intends to kind of reduce the friction of deploying a site, which means that your site can be much more dynamic.
I won’t get into too much -- well, I mean I will go into some details. What the hell. Let’s look at that just briefly.
I talked earlier on about a blob of static assets, but in this world where you’re using a tool such as Netlify, and there are a few others that are kind of doing similar things. Very broadly, they produce some build tools or they host your build tools for you. They will output your static site. They give some automation around that, and they also do things like provide API endpoints so that you can post data to their infrastructure.
You don’t need to manage that yourself. They can make that available to you, so you can post that and then it goes into the automation. It turns out that lots of these things can then be brought to bear, and you can do a lot more than you might have expected.
Ultimately, you do all of this, but in the end there’s always just one more thing that you can’t quite get to, and it’s just always out of reach. The thing that tends to happen then is people say, “Well, okay. Static infrastructure, that’s no good. Just put that in the bin. We’re going to have to go to something else.”
That’s where I differ. I think the more we can keep in this kind of slightly contained, simplified environment and then extend into other tools, the better for us. It’s not an all or nothing scenario.
That’s kind of where I’m going with this microservices thing. If I kind of wrap up this Netlify offering of all things similar and kind of put it in a kind of convenient box or something that spits out a static site, yes, we’re at the limits of maybe what we can do, but we’re at Beyond Tellerrand. This is exactly the kind of thing we should be doing. We should be looking outside of the box. We should be seeing what else is out there. This is exactly where microservices can start to enhance this kind of approach.
Let me see if I can give you a bit of an example. This is an example as simply as I can think of it for live content on a static site. How can we make use of some external service to be able to bring this to bear? And so in order to keep it simple, I’ve done it on the footer of my own site, beautiful as it is, I think you’ll agree.
There’s one item on here that’s a little bit more dynamic than other things, and that’s just simply that I wanted to put recent tweets on there. I don’t blog as often as I should. I don’t want the site to look like it’s gone dusty. It’s a static site that I have build automation for. Ultimately, I don’t have anything that’s a heartbeat that’s regularly updated. I thought, why not include my recent tweets?
It’s a good thing I did, too, because there’s gold in there. You want to be able to follow a link to find the kind of things that I’m tweeting about. A little hint, by the way. If you ever do need to conference calls from home and you have some difficult conversations to deal with colleagues, don’t have a cat yawning over your should as you’re doing it. It ruins all credibility.
Audience: [Laughter]
Phil Hawksworth: Who knew? Why knew that? It turns out I’m not the first person to know that. This guy knew that as well.
Audience: [Laughter]
Phil Hawksworth: Didn’t work out well for him. Once he got crossed, it wasn’t good.
Returning to the point, how do we make this static site feel very dynamic by having tweets up there all the time? You might be thinking, well, how could we do this? You’d be right in suggestion there is approximately one gazillion ways to achieve this.
There are lots of ways you could tackle it, but as I said, my site is a static site. The options kind of reduce a little bit. I can’t just be going off and querying Twitter whenever someone makes a request to the infrastructure. But, as I mentioned, it’s a JAMstack, so I’ve got JavaScript. I’ve got APIs. I’ve got Markup. What more could I need?
What are the kind of options and considerations for doing this? Well, yes, Twitter gave us a JavaScript widget that I could just blob on the page, so it would just pull things in with JavaScript. But I don’t love that. It doesn’t give me control over the design. It introduces some dependencies. It means that JavaScript has to load, pause, render. I have to pull things in, in the client. Also, the content, the very valuable content--I think you’ll agree in that case--isn’t part of my page. No search engine is going to find that on my site, so that’s kind of invisible, so I discounted that.
But of course another option is I could -- you know I don’t need to use Twitter’s JavaScript widget. I could just consume the feed myself and render it myself in the front end. Well again, you know, I’ve still got those rendering dependencies. I need JavaScript to execute, and it puts things in front of the render. Again, I’ve got that invisible content.
More likely I’ll probably want the content’s part of HTML, but that means I’ve probably got to have some kind of a dynamic backend. Will the content feel stale if I don’t go and run my builds frequently enough?
This is where something like this can come to the rescue. I’m going to zoom in a little bit and look at this in a bit more detail. I hope you don’t mind lines and boxes after lunch. There’s going to be a few, so buckle up.
How does my site work? Well, my site has a blob of content, and it’s got a bunch of templates. I run a build, and it spits out a static site.
Everyone okay? Everyone all right? Okay. Good.
That’s the core of what’s going on there. That wraps up kind of conveniently with some Gulp, some NPM, and a few blobs of this and that. That’s what I run in my local development environment. I can run it anywhere, but it’s nice and encapsulated.
Then it spits out the site, and then I push it up to a hosting environment. That could be anywhere. Any static host will do because it’s just static files. It could be S3. It could be Heroku. It could be all kinds of places.
But as I mentioned earlier on, I tend to use Netlify. One of the reasons for that is, rather than push the output of the build, I like to push the build itself up there, so all of my build goes into a version controlled repository. That is itself what is reflected up into this environment, this production environment.
That means that, up there in that environment, that's where the build runs now. Rather than pushing the output up, every time there’s a change to the repository the build runs there and outputs the site. It’s identical in every way to my environment.
The nice thing is that, just with this, I’ve got a Git based deployment process. Lovely. It feels nice and safe. Then it goes on and does other things like propagating to CDNs, lots of complex things that I don’t ever want to touch. That’s all kind of managed for me.
Fine. That works quite nicely, but then I want to bring in other content sources, Twitter just being one of them, but let’s start with some other things first. There are content providers that I want to consume rather than just having to author everything in my own local environment. What about content management systems as a service?
Things like Contentful do a great job of this. The can host their own content management system for me and I can just consume that data from their service. Also, they’re kind of asset pipeline, I can consume that.
What actually happens is, when I run my local build, the content gets pulled in from that hosted environment. I stash it locally. I run my build. I output the site. It works nicely.
In production what happens is the same thing. The build runs. It draws the content in from this other service. It renders it and does its thing.
In this environment already what I’ve got is, if I make a change to the code, to the design, to the templates, to the logic in my development, commit it to the repository, the build runs. It deploys. If there’s a change to the content by me or by anyone else, a Webhook is fired. That’s what the production environment is watching, and it just triggers the same build. Now we’ve got builds and deployments being fired by content changes and by code changes - really, really nice.
Now I’m introducing Twitter. Now I’m introducing that into the mix. Of course Twitter provides and API that I could just draw in as another data source. But the trick is, how do I fire the build? How do I trigger the build? Triggering the build here is the key. Otherwise I have to do this manually all the time.
Well, for that we need some kind of a watcher, some kind of a function that lives somewhere that’s going to consume the Twitter API, look for the right thing, and then fire this Webhook that will trigger the build. That seems reasonable. That seems sensible enough.
The problem is this is something that needs to stay alive all the time. I need to host this somewhere. This needs to live in an environment that’s always going to be up, always going to be running. It needs to be active, maintained. It needs to be alive.
Call me crazy. Is this not just simply a task for If This Then That? It feels like I could just lean on someone else’s infrastructure. Why would I build something myself?
If This Then That I thought had gone away. It just kind of sits there quietly in the background, and I use it for a few things: archiving tweets and posting things here and there. They’ve been adding channels over the years and creating more services that you can plug together. If anyone hasn’t come across this, it’s something where you can just trigger an event based on another event.
Critically though, they’ve recently added support for Webhooks, and I wasn’t aware of that until quite recently. Now you can both listen for a Webhook being fired and then trigger any of their other events in there, the channels. Also, you can issue a Webhook as well. Perfect for me. That means that I can set up this little channel where it just watches the Twitter stream for me. If a tweet comes in and if I tweet, rather--I kind of ignore at replies because I don’t want all of my conversations going up there--then I just make a request to an HTTP endpoint. That’s what runs my build.
In this way I just kind of jiggered this around a little bit. These kind of content sources, you can kind of bolt them all together, a bunch of different sources. Some of them are things like Contentful. Some of them are Twitter. There might be Instagram. Any source that can expose a feed, ultimately I can bring that content into my production environment, and I can bring it into my development environment, so I can get at the sources. Then through a simple, little tool like If This Then That--actually there’s quite a lot of power there--I can actually start observing for changes in those feeds and then triggering builds.
That kind of works kind of nicely for this use case. It’s simple. I’m leaning very much on the service of someone else, but it does what I need. Whenever I tweet, a minute or two later my site is refreshed. I never need to touch it.
That’s fine, but sometimes we need a little bit more power than that. If you’re thinking, by the way, that this line is purely as an excuse to put up a Star Trek picture, that’s fair, but you’d be wrong because, if I wanted to do that, of course, I’d use this picture.
Audience: [Laughter]
Phil Hawksworth: I don’t know. I have no idea what caption I could use to shoehorn this in, so I just decided to use it for my little water break.
Audience: [Laughter] [Applause]
Phil Hawksworth: Yeah. Me too. Me too. I’ve got so many questions, but there we are.
Anyway, where were we?
We need more power. We need more control. Something like If This Then That. That feels like a hack in many ways, but we’re leaning on another service. But we need a bit more control.
When we’re thinking about these kind of microservices, I’m starting to think of this as my kind of server side logic that is just on someone else’s server, you know, some infrastructure that’s elsewhere. Let’s kind of simplify this again, and I just put a box over that. It doesn’t matter what’s happening in that box. Let’s just think of my static site or any static website that could be served. Then it has some server side logic that sadly there’s no line to it. It can’t -- the two can’t coexist.
A way to get around this is by adding a layer or routing in here. Now I like this very much because it means lots of requests that come to the site, those just get served by the static site. But there will be some that can’t do the things that can be achieved by a static website or what I’ve got on that site. That’s the opportunity to use this routing to pass it through to some other microservices or any services elsewhere.
What we’re doing here is we’re offloading the complexity. I talked about reducing complexity, but I’ll be honest. I’m selfish. I only care about reducing the complexity for me. The fact that someone else is hosting something that’s very complex and very powerful, that’s fine because, as I said before, I’m very happy using other people’s plumbing - still not comfortable with the term.
And so, you know, this is a process that I kind of like. There are lots of trends toward offloading complexities to other people. If we look about, look at the way that kind of hosting and infrastructure has gone over the years, way back when, once upon a time, it used to be you used to own all the metal. You used to own the room it lived in, the power supplies, the UBS, the backups, the racks, the networking, the servers that went into the racks. You had to do it all. But then, after a while, you’d rent space in a rack. All of the power supply, the network, and all of those other bits of infrastructure were provided for you. You’ve got a physical device into a rack and plug it in. You’d rent that space.
As time has moved on, now we’re starting to rent virtual servers. We rent them as software. They’re virtualized and we can rent an entire private server that way. Even more popular now, we’re starting to see renting spaces within virtual environments, things like Heroku and sites now are very, very quick to be able to provision virtualized environments. And so it feels like the pieces are getting smaller and smaller.
We’re getting to the stage now that you’re renting CPU time for your function. You don’t need to care about any of the infrastructure that lives around it. You just care about that one function that’s doing that one job that you need. It feels like a very, very simple thing, but there’s huge power in that, I think, if you’re liberated from having to care about all of these other bits of infrastructure that’s dealt with by those one-man-bands that we’ve seen.
What we’re talking about is having a function where magic happens and that being available on some URL. Then when you make a request to that URL, the function is invoked, it does whatever it does, and it returns or does something. This is a great way to leverage other people’s infrastructure if we can do this. The most popular one that people would be familiar with would be Amazon Web Services Lambda, which is these functions as a service.
The way into that, Alexa is building Alexa skills as a build on Lambda, and Lambda is very much the -- or rather, Alexa is the gateway drug for Lambdas, I think. Have many people in the room actually built a skill for Alexa? Just very curious.
I can see there are a couple of hands. There are a couple of hands up there.
It’s really good fun because you’re writing just a small collection of functions. You’re putting them somewhere magical. Then, before you know it, those skills can be invoked by this speaking box in your room.
My first skill was of course mapping a JavaScript object, which had the dates in it, which indexed the types of recycling and refuse bins that I need to put out. I could say, “Hey, Alexa. Ask Monkey Helper,” because Monkey Helper was the name of my skill, “which bins to put out.” It tells me which bins are coming up next.
I feel like I’m living in the future. I’ll be honest.
Audience: [Laughter]
Phil Hawksworth: It was a wonderful day. My wife, less impressed, but I don’t care. The gates have blown open for me now, and this is the gateway into building skills on Lambdas. But these are just functions that live in someone else’s infrastructure.
Amazon aren’t the only people who are providing this. Google are providing this as well. Their Google cloud functions is in beta at the moment, but it’s maturing really, really fast, and it gives access to lots of their infrastructure as well. Microsoft has Azure functions, which these are all much the same kind of thing.
They are functions as a service, and they’re all maturing and getting much more popular very, very quickly. They really unlock the power of being able to route some requests off to some other place where you don’t have to worry about how those are maintained. You just have to worry about the code, the stuff that you’re probably already optimizing anyway, you’re already doing a good job of.
This routing piece, this is tricky. It took me a little while to arrive at this conclusion that this is something that could be done sensibly. There was actually an article in Smashing mag. Stefan Baumgartner wrote a really interesting article about static sites on Smashing mag, which talked about using static sites as scale, you know, far beyond anything that I’d done.
One of the key tenants of that was routing between what was static and had been deployed and what was still a dynamic site that had yet to be replaced. And so this idea of conditionally just choosing what’s going to be served in this way and what you farm off to other microservices, or other services for that matter, is really key. That’s going to be tricky to do. No one really loves spending their time in Nginx or Apache or wherever else is configuring these redirects.
I kind of was delighted once again by this Netlify service that makes redirects really simple. I just want to show you a couple of things here that I think are really powerful. It starts off very, very simply. Just a redirects file, by the way, in the root of your static site. Then they’ll configure the redirects for you.
This is a very obvious, simple example to start with. Anything that’s served currently on a home, /home directory, you want to redirect the user just to the root of your site. Or if you’ve got a blog post that has a file extension .php, you might want to actually redirect them to the URL that doesn’t have the file extension on there, so you’re not so tightly coupled. It’s a bit kind of tidier.
If you’re someone like me who once upon a time had their blog on the URL journal because you thought it sounded learned, when you changed your mind and went back to serving it as blog, you didn’t want all of those links that were out in the wild linking to something on journal to not exist any more, so you can provide the redirect that way.
The nice thing about this is that in this configuration you can also start to specify the type of HTTP response code that it provides. You can say what kind of redirect it is. Further to that, you can start also doing things like giving custom 404. If you can declare something as a 404, and this is the redirection that should happen. They can be different at different parts of your site.
It gets better than that. It seems very simple, but it starts to get quite powerful. Since this particular provider, they do all of their redirects out of the CDM level, and these are distributed around the globe, so you can start to do things like geo location in your redirects. They’ll do this for you, so users who are connecting in China, Hong Kong, or Taiwan, they can be redirected from the root of your site to the part of your site which is specifically serving Chinese content. This is done by keying the country that’s found there in the geo IP.
It goes further. You can start to do things based on the language. If someone was using Chinese as their language, it actually takes you to the traditional Chinese part of the site as well. It gets really, really powerful.
Then I already showed you, in the last example, wildcards and splat, so you can be picking up parts of the path and passing those through as variables, which of course is key to the next one, which is the one that actually is where the exciting thing for me is, and that’s proxying so that you can specify a root in your site and pass all requests that come to that off to another service, invisibly to the user, return it as a 200, and that way you can start handing things off. This feels very simple, and it feels quite mundane, but I think there’s huge power here. It provides it as a way to decouple our simple kind of static infrastructure and then start to route things to other services, these microservices that other people maintain for you.
I’m going to give another example, and this is of user generated content, which is a ceiling I always bang my head against if I’m trying to build something statically. The simple use case, let’s just describe it. I’m showing my agency roots by thinking about this example. There’s maybe a site that would be about a campaign. You want to have some content that’s about the campaign. But you want to use this to be able to create something when they get there. They’ll read about the campaign, but then they’ll create, let’s say, a custom poster either from a choice of images or maybe they’ll upload their own image, add their own message, and then create some kind of a unique poster that will annoy their friends on Facebook if they do choose to share it.
This is a pattern I see quite often, this kind of a need. There’s no way I would go near a static site architecture for this unless maybe there are some microservices that I could lean on. Let’s walk this through. Let’s wire frame this puppy. Let’s just look at the flow a little bit more.
I mentioned there’s a homepage. There’s some kind of landing content. There’s always going to be some kind of about page, some terms and conditions, some other boilerplate, some legals, whoever knows what else, those kind of pages. There might be a page specifically about this campaign teasing what you can do and then some kind of call to action for you to make your own bit of content. Then a page that provides the UI to do that where you can upload your image, choose and image, enter your content, manipulate it, and then hit the magic button that then creates that asset, creates a URL that it lives on so that you can save it, share it, do whatever.
Actually, when we look at that, the majority of that is static. At first glance it felt like it was going to be a complete no-go, but actually, really, everything up to here, even up to the creation of that asset, that’s all just the same. There’s no difference for any user. They’re all exactly the same thing. They’re static. Yes, they’re manipulating the content in that creation page, but we’re just talking about form, really. Then on from that where you post to, where that endpoint is where the data is consumed and what generates the output, that’s the thing that’s dynamic.
Let’s see how that works then. That’s fine. It feels like we can have routes for the home, for the about, for the campaign, for the create page, all routing straight to the static site. They just serve the static pages, serve the static assets.
Then requests may be posting to the URL poster or doing a get request to poster with an ID that’s being returned from previous generation. Those are the kind of things that we’d route off to our function as a service. That’s where the mechanics can happen. That’s where we can generate the image assets. We can stash those image assets somewhere. We can serve the specific poster, the specific request that’s being asked for that’s different to all of the others.
This feels like a very clean separation where actually the number of things you’d have to maintain, they’re just code. There’s no real infrastructure that you really have to maintain and own with that. This kind of separation seems to be working out quite nicely.
Now managing Amazon Web Services can sometimes be a little tricky. It’s how I’d summarize my experience. It can be tricky. It can be really painful at times. You can find yourself in a rabbit warren of documentation. If I started off at the beginning of this talk saying simplicity is the key, you might be saying, well, you know, AWS isn’t that simple. But the good news is that there are tools to help us now. There are lots of things on their way.
Anyone who has played with things like Lambda may have encountered this, which is something called Serverless, which is a set of libraries and tools that sits on top of that. It’s intended to kind of ease the workflow of creating these Lambda functions and deploying them. It actually really smoothes out the process. It also doesn’t just work for Amazon. It works for Microsoft Azure, for Googe Cloud Compute, for IBM OpenWhisk, which is another service I forgot to mention at the start. This is a really powerful tool that can help you get underway quickly and just keeps you in a familiar environment writing code, deploying it somewhere.
There are others. This is one that I particularly like, the name of which I can no longer read: Webtask.io. Webtask is another one of these providers that makes it really, really simple to start writing code and then getting to execute that on an endpoint. I don’t think you’ll be quite able to see that, but even just on their site you can start experimenting with this and seeing how quickly you can start deploying something that you otherwise need an environment for.
There are others. I could mention a bunch. But I’ll just mention this other last one, StdLib. This is another kind of similar to the others, but it’s actually starting to become like a marketplace for these functions as well. People are starting to build utility functions that are deployed into an environment that can then get executed. Kind of think of it as NPM for Lambdas if you’re a JavaScript bot.
I’m conscious time is getting on, and so I kind of want to get to a few kind of takeaways from this. I’m talking a lot about simplicity, and I’m talking a lot about the ownership of infrastructure. But really I think there is power in avoiding responsibility. Now I’m fairly sure that’s not the quote, but that’s fine. I’m going to reappropriate it a little bit.
What I’m talking about here is that there’s a lot to do when we’re building sites and we’re maintaining sites. Anything that you can offload to an organization, which is frankly going to be way better than many of ours is at provisioning, infrastructure, keeping it on all the time, making it incredibly performant, all of those things that go along with it. That can be very liberating. It means you can concentrate on the other things. Avoiding those responsibilities and then taking responsibilities for the things that are your specialty, I think that’s quite an empowering thing.
I’d also say, don’t be afraid to start small. No, it’s not an all or nothing thing. Hopefully the examples I showed just illustrate the fact that you can take one small piece of your puzzle and use a microservice for that. You can use a function as a service just to serve that one thing. That’s great. That works really nicely. It can scale out hugely from there. I think the possibilities are endless.
It is a bit intimidating, so my last takeaway is I’d say don’t be intimidated. Tooling is coming. It’s getting easier and easier over time. I think that as more--
Audience: [Laughter]
Phil Hawksworth: Isn’t that amazing? Whoa.
As more tools come along and more services come along, we’re going to see more of this, I think. It’s going to become very popular and the tooling, of course, will improve.
Kind of summarizing, I said at the beginning, complexity can be a barrier and simplicity can be a real enabler. I think by focusing on the things that are simple, this is really great for us because simplifying isn’t dumbing down. It’s focusing on what matters.
With that, I think I have about one minute left, so I will call it a day. Thank you very much for listening. Thank you for staying awake.
Audience: [Applause]
