In the fast-paced field of cloud services, staying current with service updates is often challenging. The recently announced StackFeed aims to address this issue, especially for software architects managing multi-cloud architectures. Architects select cloud services they're interested in, and StackFeed generates a customised service update feed consumable using an RSS reader, Slack or Microsoft Teams.
Jacob Shadbolt and Victor Leach, co-founders of IcePanel, a collaborative diagramming tool for software engineers, and Chris Saganic, senior software engineer at IcePanel, created StackFeed. The team experienced the challenges solved by StackFeed first-hand:
All three major cloud providers push updates constantly, but finding the relevant updates is pretty challenging - like drinking from a fire hose. Being on top of these updates is incredibly important, either to make improvements and optimisations to the services you provide to your customers or, more drastic, to a service you're reliant on is being deprecated. Each company and team's service/technology stack is unique, and getting all updates on tap is just too much to digest.
Context diagram of StackFeed.io
To create the StackFeed backend, the creators manually catalogued 600 cloud services in a Google sheet and imported that sheet into a Firestore database. An automated script runs hourly, scraping the RSS update feeds from the three major cloud providers to fetch new articles published in the past 72 hours. StackFeed then scrapes the URLs for each update to get the article's long-form body, converts it to Markdown, and inserts it into the database. StackFeed also runs a build of its front end that uses the database articles every hour.
App diagram of StackFeed.io
The front-end architecture of StackFeed employs hybrid rendering, converting each service, initially JSON data from the Google sheet, into a user-friendly format. StackFeed uses server-side rendering (SSR) for the feeds and the article content, and users can pass services through on a query string to create custom feeds. Nitro on Netlify functions handles the deployment, allowing SSR at the edge.
InfoQ spoke with Shadbolt regarding StackFeed and its implementation.
InfoQ: What were the main challenges in building StackFeed? How did you overcome them?
Jacob Shadbolt: The main challenge in building StackFeed was manually cataloguing the ~600 services from the three major cloud providers. The inconsistencies in how each service is managed, documented and updated were honestly surprising, so unfortunately for us, automating this didn't work. The solution was to manually sit down and enter data into a spreadsheet, which we use to manage StackFeed.
InfoQ: In your opinion, what are the main challenges facing software architects nowadays?
Shadbolt: The title "architect" holds a history of a top-down "ivory tower" decision-maker, with some companies removing the title from their employees due to its corporate and dictatorial-like past. However, in reality, the role has and still is transitioning into a collaborative facilitator, aligning business, product and engineering teams on design decisions.
Keeping informed about how a business' software system(s) work is challenging, even before working out future strategic moves for that company to stay ahead of its competition. If you add in the rate of change of systems, service dependencies, new trends and a distributed/more autonomous team - you've got a whole pile of problems to deal with strategically. I see a resurgence of the architect's role and responsibility to oversee the technical decisions and relate those to the business and product objectives.
InfoQ: You're also a co-founder at IcePanel. How does IcePanel fit into solving these challenges?
Shadbolt: The entire technical and non-technical team should have a place to understand how their software systems work from context to code. Diagramming tools aren't suited for the job, as systems are incredibly complex, and the static, unlinked diagrams used to visualise that complexity make it nearly impossible to document accurately (or remain up to date).
Most assume you should automatically generate design documentation, but we believe that's wrong. Design should be top of mind when solving your system's problems; the human element is required to make those decisions understandable to others. Removing the human element means you end up with a web of information that may be accurate but needs to be more abstract for human consumption. We're striving to be the tool that gives teams complete visibility of their technical design, both now and for the future of their solution, linked and informed by changes in reality.
