CSE 370: Software Engineering Principles

Aiden O'Brien

Aiden O'Brien looked out of the office window and admired the view of the pedestrians below as they crossed the River Corrib on the Wolfe Tone Bridge. Although lunch hour in downtown Galway, Ireland was in full swing, there weren't as many people out and about as there normally were. Maybe a walk would do him good since he could avoid the normal press of people in the downtown area. Anything would be better than trying to make the decision he'd been agonizing over. Life had been pretty good to him so far—but lately the pressure has been ratcheting up. Aiden sat back in his chair and started to think about how it all came about.

More than 10 years ago, Aiden joined the company MyHomeStuff.com as one of its first Irish employees. The company was founded in the United States, but labor costs in Ireland were favorable, so the company sent their Chief Technical Officer out to Ireland to see about hiring a team in Galway. Aiden was among the first to sign up, and the team had grown steadily since then. There were now three teams in Galway, and each of them had their own team lead who reported directly to Aiden, who was the Director of Software Engineering for the Irish office. Initially, the teams in Galway were given side projects with a limited impact, mostly because the US based company was unsure what they were going to get. With several successful projects behind them now, the company was sending more and more meaningful work their way.

Three months ago, the biggest project yet was sent to the Galway office—the launch of MyRugsStuff.com. This was meant to be a sister web site to MyHomeStuff.com but with a narrow focus on the lucrative rugs category, and an experience tailor-made to customers buying rugs. The hope was to move the rugs business from MyHomeStuff.com to the new site in a seamless way. The company had aggressive goals for growing the rug business that just didn't work within the confines of the old MyHomeStuff.com site. The plan was to have the new site ready to go in just six months.

Despite the tight timeline, the team in Galway had seen this as an opportunity to build an excellent website from the ground up using the latest technology stack. Work on the older MyHomeStuff.com site was more difficult and subject to outdated processes and procedures. This was a chance to do things in a better way. The developers were beyond excited about this opportunity.

For months now, the Chief Technical Officer of MyHomeStuff.com had been preaching the virtues of using the DevOps methodology. He wanted to see teams make frequent small changes that were continuously deployed to production. This would deliver valuable features to the customers more quickly than ever. The company signed up with a large DevOps platform in hopes of moving most of the deployments to this cloud-based system over time. However, this required a huge change in processes and infrastructure for the company, and many teams struggled to adopt this change.

One thing that made adoption difficult was the prevalence of monolithic services. Throughout the years the teams at MyHomeStuff.com had created large, highly scaled services to handle different aspects of the business such as product details, pricing strategy, promotions, search results, and of course cart management and checkout with various payment methods. These large-scale services had a very complex deployment strategy complete with rollback plans, heavily scripted installs, and manual interventions. Moving these large-scale services was going to take a long time, and the pressure to deliver new features was always present. Finding time in the schedule to make the move was an ever-present concern for many teams across the company.

For Aiden and his team, the assignment to build this new business presented an immediate opportunity to move to the DevOps platform and start using microservices instead of monolithic services. The idea behind microservices was that you could create small, narrowly focused services that served only a few well-defined functions, and string them together to accomplish your goals. This would allow the team to do small, frequent deployments, reduce inter-team dependencies, and make it easy to adopt and refresh technology with the latest and greatest offerings.

Because this was a brand-new effort, also known as a greenfield project, the team had to design everything from scratch. Aiden had stressed to the teams that they needed to be sure that everything built had good design documentation. In the past, Aiden had spent signficant time reverse engineering systems that needed to be upgraded, but lacked documentation. If the teams were going to do things well, carefully documented designs needed to be an integral part.

Aiden had intended to do a design review on every system before getting started, but things were moving fast and there were a lot of moving parts. Before long, Aiden was just checking to make sure that a design document of some kind had been added to the wiki before work on each microservice began.

The teams worked quickly and before long, there were more than a dozen microservices deployed on the DevOps platform. Of course, everything was behind a feature flag, and customers could not yet see the MyRugsStuff.com website until the official launch, but the developers and internal stakeholders could see progress on the site in near real time.

Eventually, the security team had reached out to see how things were coming along. With the halfway point nearing, they thought it would be prudent to do a quick security review to see if there were any holes to plug. Aiden had sent them some preliminary information then forgot all about it. There were plenty of other things to keep him busy.

Aiden winced as he remembered the unexpected Slack message he received from Brennan Gallagher, VP of Security in the US.

Aiden had gone to the corporate wiki site where all the design documents were stored and had found the design page for authorization details, glanced over it, and then pasted the URL into Slack for Brennan to review (See Exhibit A). It wasn't long before the reply came back.

Aiden went back to the wiki page and reviewed the diagrams, this time with a more critical eye. There was a box-and-stick diagram that had been drawn on a white board with some handwriting that wasn't easy to read. This diagram showed how the browser might interact with the authentication service and other downstream services but only at a high level. There was also a UML sequence diagram that showed calls between the browser and the backend authentication service, but without much detail about where or how the JWT token was stored. It was clear that in the rush to start development, only the barest of details were provided about how the authorization system really worked.

Frustrated, Aiden reached out over Slack to Jericho Forbes, lead for the team who built the authentication service. Jericho Forbes was also one of the early Irish employees at MyHomeStuff.com. He was very close friends with Aiden, and had previously been instrumental in the success of many of their previous projects.

Aiden got right to the point.

This was indeed bad news. StuffPlus memberships cost about $49 and gave users access to extra savings and special deals. These deals could not be made available to just anybody, otherwise the program would not pay for itself, and the company could lose money. Reluctantly, Aiden reached out to Brennan to share the news. As expected, Brennan insisted that the problem be rectified immediately, and that a new authorization scheme be implemented so that this couldn't happen. Although Aiden had agreed to make the change, he stressed to Brennan that the site was not in production yet, and there was a great deal of feature work on the schedule that would have to be rearranged to accommodate his suggestion. Aiden would have to discuss the matter with Sean Haskins, the VP of Emerging Business who was overseeing the project.

Sean was based in the US but despite the time difference was pretty good at answering the phone at all hours of the day. Sean pointedly ignored any attempts to reach him over Slack, though. A phone call would have to do. Aiden picked up the phone and reached out.

The phone call ended abruptly, as it often did with Sean. Looks like a war between the VP of Security and the VP of Emerging Business was now brewing. Maybe going home now was the right solution for today.

The next day, Aiden arrived at work anxiously waiting to see what Slack messages and e-mails might be waiting for him. Before he had even settled in, Jericho burst through the door.

"We need an API Gateway".

"A what?" Aiden had asked.

"An API Gateway, like the one the MyHomeStuff.com site uses. This allows us to reconfigure the security stuff with a single service and forward the calls to the appropriate microservice. We could probably do this in just a few days."

Aiden was familiar with the API gateway used in other parts of the company. The idea was intriguing, but he knew no design change was ever that simple. Aiden put his fingers together and looked across at Jericho.

"Convince me—why do you think an API Gateway is the best way to go here?"

Jericho smiled. "Like I said, we could implement this in just a few days. There is open-source software out there that does all the heavy lifting—all we have to do is create a simple configuration file. The gateway can handle all of the requests and make sure they are authenticated, then pass them through to the right service. That means in the future if we have to do any updates to security we only do it one place. Also, we can add other features like request logging that makes auditing much easier as well. If you want, we can get started on it today!"

"Well, hold on. This is a pretty big change. Let me talk to Alvin Peters who is over the API gateway to get his opinion as well."

"What is there to discuss? The API Gateway is a standard practice everywhere. That's why they included it on our main web site. Honestly, Aiden, I have been thinking about this for a while and wanted to bring it up with you earlier, but you're always so busy. I really think we need to get going on this as soon as possible. We should have done this from the beginning."

Jericho turned to leave, then turned back, "Oh, and just so you know, I spent some time last night documenting the design so you could see what that might look like. It's a child page under the authentication page on the wiki now."

"Well, let me chat with Alvin and I'll let you know what I decide. Thanks, Jericho."

Jericho stepped out of the room and Aiden quickly pulled up the page. Indeed, Jericho had put together a very helpful diagram. The diagram showed how the client would call the authentication service, set a secure cookie on the browser, then subsequent calls to other services would read the cookie before forwarding to downstream services. It looked rather straightforward. Aiden was grateful for the complete documentation.

It would be a few hours before Alvin, who was based in the US, would be to work. Aiden sent an e-mail asking him to reach out as soon as he was in the office and available. Thankfully, a few hours later Alvin reached out over Slack.

So there it was. It seemed like there was no straightforward answer here. If he added the API Gateway like Jericho suggested, then they would probably deploy on time and everyone would be happy. Of course, if they did add the API Gateway, it might just be the beginning of another long-term series of headaches.

Aiden glanced at his inbox. There were recent messages from Brennan and Sean that were unopened. Just then, a Slack message appeared—from the CTO! Looks like this is a decision that could not wait any longer.

Exhibits

Exhibit A: Sample Wiki Design Page

MyRugStuff.com Authorization Service Design Page

Overview

The MyRugStuff.com Authorization Service is used to authenticate and authorize users of the MyRugStuff.com website. It relies on the existing MyHomeStuff.com authorization service to authorize existing customers. It returns a JWT token to the browser of the user once authenticated.

Helpful Diagrams

Call Sequence

Endpoints

{ "id": "1234567890",
"fullname": "John Doe",
"privilege": [List TBD] }

Back to content ↩