[HN Gopher] Launch HN: IcePanel (YC W23) - Onboard engineers wit...
___________________________________________________________________
Launch HN: IcePanel (YC W23) - Onboard engineers with explorable
system designs
Hey HN, Victor and Jacob here. We're excited to show you what we've
been building over the last couple of years! IcePanel
(https://icepanel.io) helps architects and developers easily
explain how their software works with interactive and explorable
diagrams. Modern systems are complicated, and getting new
developers up to speed and contributing fully is time-consuming and
difficult. It costs the new developer's time, as well as the time
of the senior first/second generation developers who help them
constantly through their first 6 months. The resources people use
to learn new systems are usually scattered across a maze of
artefacts, like confluence pages or outdated draw.io diagrams,
which are usually incomplete, with the 'real' understanding of the
system being tribal knowledge in the team. As discussed in
yesterday's post https://news.ycombinator.com/item?id=34328069
"documentation only works up to a point" and we believe this is due
to docs being disconnected from the code. A map of your software
architecture for current and future design, linked to code, gives
new team members a trusted way to learn tribal knowledge. Before
IcePanel, Jacob was part of a cross-functional team in a large
company, where they'd have regular meetings about the technical
design. People would draw boxes and lines on a whiteboard or
present Bollywood-themed Visio monstrosities that nobody truly
understood (impossible to find in Confluence/Sharepoint). Depending
on the people invited, 1-hour meetings cost the company thousands
of dollars, and there were often no outcomes. We both felt the
tools in this area were not working, and there was space to build
something awesome. We built IcePanel on top of the c4model.com, a
simple set of abstractions for audiences with different technical
abilities. The simplicity of the C4 model works well for teams who
practice "just enough architecture," and fits with a vision of
democratizing architecture across dev teams. We also work with our
larger customers to help with the scaling challenges of the C4
model and have built features like tags and flows that add
interactive overlays on top of C4 diagrams. Most diagramming tools
are generic and flexible for any purpose. This is great for quick
sketches and whiteboarding but painful for creating longer-term
documentation where it's important for objects to contain metadata
and have relationships with other objects. The benefit IcePanel
has over diagramming tools such as draw.io/Visio is how it uses
modelling, overlays and links to reality to keep your diagrams up-
to-date and allow engineers to find the code they're interested in
faster. Model changes are automatically synced across all diagrams,
and you can refactor connections or the object hierarchy. We use
interactive overlays to add/remove information rather than creating
new diagrams for every new topic of conversation, meaning fewer
diagrams to maintain. Objects in IcePanel can be linked to
resources in the real world, such as source control, wiki pages or
cloud resources. This allows developers to learn about resources of
interest faster, and you'll be alerted if those resources no longer
exist, prompting you to update the model or diagram. Thanks very
much for reading! We'd be grateful to anyone who checks out our
website (https://icepanel.io), interactive demo
(https://s.icepanel.io/vmHvBHr4BeMEOa/bPBR) or leaves a comment
with thoughts and feedback. Happy to chat!
Author : JacobShadbolt
Score : 86 points
Date : 2023-01-11 14:46 UTC (8 hours ago)
| spamtarget wrote:
| you still did not learn that if you want to show off your work,
| you dont ask for signing up or any of that BS. it's 2023
| zomglings wrote:
| I found the interactive demo overwhelming and very difficult to
| unpack.
|
| It would probably be much easier to understand if it was a system
| I worked on every day.
| victor96 wrote:
| Maybe as the demo link we provided takes you into a flow. You
| can try the following one which has less going on.
|
| https://s.icepanel.io/vmHvBHr4BeMEOa/0YRL
| VectorLock wrote:
| Can you import existing C4 models/diagrams into this?
| victor96 wrote:
| What format are you thinking? We import Structurizr workspace
| JSON files, which can be exported from the DSL.
| VectorLock wrote:
| In my case, PlantUML.
| victor96 wrote:
| We don't import PlantUML directly yet, but something we can
| look at.
| VectorLock wrote:
| That'd be pretty cool!
|
| I'm curious what JavaScript/React libraries do you use to
| generate your lines and boxes visuals?
| victor96 wrote:
| We use https://pixijs.com, great project!
| VectorLock wrote:
| Cool! Does PixiJS draw the arrows and boxes and stuff for
| you or did you have to implement that yourself?
| victor96 wrote:
| PixiJS is a bit lower level, it has some primitive shapes
| like line/box but we draw most things ourselves.
| fallingmeat wrote:
| isn't this what mbse (i.e. represented in sysml) is for?
| victor96 wrote:
| I'm wondering if things like SysML and UML are too heavyweight
| for most modern teams, who work in agile ways.
| ctvo wrote:
| Is the next step creating and updating these diagrams
| automatically? That dream seems to come up and die in cycles over
| the years, but it may be possible now depending on the compute
| platform and network appliances you use. This push to automate by
| doing interesting things, like reading your network traffic
| (https://www.akitasoftware.com/), could work here.
|
| I'm unsure, as is, how you fix the organizational and human
| problem: It takes effort to initially create these diagrams, and
| constant work to keep them updated as systems evolve. How do you
| make that easier? A more fancy diagram explorer seems... not as
| useful.
| victor96 wrote:
| Automatically generated diagrams seem to be the dream for many
| of the developers we chat to, however we don't see this working
| as great as they believe. This is due to "the model code gap"
| which is where the abstractions we use to discuss software
| architecture rarely matches 1:1 with the source code. You can
| read more about this on our blog article below.
|
| https://blog.icepanel.io/2022/11/30/the-model-code-gap
|
| We think this is more of a human/organizational problem rather
| than a technical one and we have tons of ideas about how to use
| links to reality to help humans keep docs up to date. For
| example an object which has had a lot of commit history
| recently probably needs the diagrams or docs updating.
| ctvo wrote:
| I'm not sure I understand. A system diagram from source code
| or infrastructure alone is difficult, but adding some
| constraints and boundaries may help?
|
| What if we only cared about http based services and the
| boundary is at the service layer? A sidecar running alongside
| your deployed service keeps track of incoming and outgoing
| network requests. Each sidecar is configured with metadata:
| The service name, hierarchy -- it belongs to this even larger
| service, it's this architecture, and using this runtime, ....
|
| Collecting all of this telemetry along with the metadata
| would allow you to generate a graph of services in the entire
| system, who their callers are, and what they call, right?
| Even that's helpful as a starting point, where I can then go
| in and fill in the details. When I add a new service, it
| shows up automatically and is flagged for me to review.
| victor96 wrote:
| Yeah that makes a lot of sense, we definitely believe there
| are automated ways to help speed up the
| modelling/diagramming process. Such as automatically
| populating certain levels of the model from resources in
| reality as you described. Possibly integrating with
| something like backstage.io could also be super
| interesting. Then you can create diagrams quicker from a
| pre-populated model.
| Veuxdo wrote:
| > I'm unsure, as is, how you fix the organizational and human
| problem: It takes effort to initially create these diagrams,
| and constant work to keep them updated as systems evolve. How
| do you make that easier?
|
| This is one of my primary goals with Ilograph[0] because, as
| you noted, diagrams that are hard to maintain don't get
| maintained (and very quickly lose value). It takes a three-
| pronged approach to solving it:
|
| 1. Model-based diagramming. All components in the diagram are
| part of a model. This means components can be used in many
| different diagrams (called _perspectives_ in Ilograph) and kept
| in sync. It 's kind of like having static type checking for
| your diagrams.
|
| 2. Diagrams are 100% laid out by machine. Diagrams created
| using drag-and-drop tools are practicably unmaintainable[1].
|
| 3. Perhaps most important, the tool has a full IDE with
| autocompletion to assist with developer ergonomics. Every
| little bit helps.
|
| [0] https://app.ilograph.com/ [1]
| https://www.ilograph.com/blog/posts/its-time-to-drop-drag-an...
| EarthLaunch wrote:
| I finally got a chance to try this, and I'm impressed. I love
| the interactive examples right on the site. I'm coming from
| Mermaid[0], which falls more under 'pure diagramming', where
| as this is...systems diagramming. Thanks for sharing it.
|
| 0: https://mermaid.js.org/intro/
| makestuff wrote:
| I think this is purely a tech industry problem of move as fast
| as possible. Other engineering disciplines have detailed
| diagrams (breakdown of car parts for example and how to put it
| back together). It is just not a priority in the tech industry.
| Until regulation forces fines for software bugs or outages
| there will never be a priority to pay people to maintain
| documentation.
| brickers wrote:
| Not sure if you're intending this to be usable on mobile but I
| found some usability issues from a few minutes browsing on iPhone
| (I most definitely intend to have a proper look on desktop later
| - looks fantastically useful): 1- overlapping text/images in
| header; 2- list of steps was the first thing that was open - took
| me a minute to understand I could close that to get to the
| diagram; 3- I couldn't work out how to zoom in on the diagram (it
| was very small) - the expected pinching didn't work;
| JacobShadbolt wrote:
| We haven't focused on making the editor mobile friendly as most
| diagrams are too complex for such a small screen - hence why it
| sucks on mobile. I'm sure it's something we could improve later
| on as an "on the go" mode, but for now it's not been a
| priority. Is there a use case to use this on a phone?
| Terretta wrote:
| The iPad Pro 12.9 has a better (higher resolution) screen
| than most business users.
| brickers wrote:
| It seems like a sensible choice that mobile isn't your focus
| - I'm just chilling on the sofa browsing HN after work... I
| don't think I know the product well enough to comment on a
| mobile use case, but I'll let you know if I think of
| something when I take a further look
| tobr wrote:
| > Is there a use case to use this on a phone?
|
| You should probably be thinking of it the opposite way, is
| there a reason people wouldn't use it on their phones? It's
| on the web, the web is on your phone! People use their phones
| all the time for work-related things so they are going to
| expect this to be available there, too.
| xwowsersx wrote:
| I disagree. Sure, we use our phones more and more and
| expect an increasing number of apps to work on them, but
| sometimes we arrive at a site that we understand can't
| really provide meaningful usability on mobile. A complex
| architecture diagramming tool is something I expect to dig
| into on my desktop. Perhaps _some_ functionality could be
| optimized to work on mobile or, at the very least, the app
| should recognize you 're mobile and not just crap out, if
| only to say "You should open this in a desktop browser."
| But I really don't see the use case for casually browsing
| an architecture that explains how my VPC connects to the
| IGW and NATGW and which private subnet my foobar is
| deployed into. And if for some reason I do arrive at that
| diagram, I kind of expect it to be a less-than-ideal
| situation on mobile.
| kyawzazaw wrote:
| Maybe on an iPad but on a phone?
| victor96 wrote:
| Diagramming on a tablet is an interesting idea, maybe it
| can provide a better whiteboard-like experience.
| kyawzazaw wrote:
| I was thinking of consuming content only, not creating
| victor96 wrote:
| Yeh it would work better for consuming
| jon-wood wrote:
| I love this, and will be giving it a proper try later this week.
| For years I've been talking about wanting a diagramming tool that
| can give a super high-level view when needed, but which allows
| zooming in to individual components in order to get more detail.
| JacobShadbolt wrote:
| Let us know how you get on and any feedback you have!
| pimlottc wrote:
| "Explore yourself" sounds like advice from a self-help book.
| Something like "Explore on your own" or "See for yourself" is
| clearer; or even just something like "Explore the editor" would
| be fine.
| victor96 wrote:
| good catch! we've pushed a quick update to this.
| mritchie712 wrote:
| Very nice, what lib are you using to generate the canvas?
|
| I'm looking for something like tldraw[0] for Vue.
|
| 0 - https://github.com/tldraw/tldraw
| victor96 wrote:
| We use https://pixijs.com for the interactive canvas, we found
| it to be super powerful and performant. It also has a great
| open source team behind the project shipping big updates.
| ActionHank wrote:
| Looks like it's PixiJS
| bcjordan wrote:
| Couple UX nits from my first experimentation (though you may have
| already considered and have good reasons for current
| implementation!)
|
| - normal scroll (instead of ctrl+scroll which is typically used
| for making text larger) for zooming in / out
|
| - holding center mouse button to pan around (currently scrolls
| page instead)
| victor96 wrote:
| Thanks for letting us know, we'll look at getting those fixed.
| jeremyjacob wrote:
| On the web at least I am used to ctrl/cmd+scroll to zoom,
| shift+scroll for horizontal pan and scroll for vertical scroll.
|
| Middle mouse drag should definitely pan.
| gorango wrote:
| I believe this is a matter of individual preference and I think
| providing users with options to change these mechanics would be
| great! I 100% agree that center mouse + move should pan. But I
| also prefer the current scroll and I would like Shift+Scroll to
| scroll horizontally (as it does on any other web page).
| victor96 wrote:
| Thanks for letting us know your preference here, will look
| into it!
| victor96 wrote:
| We found trackpad/mouse in the browser to be a bit of a
| headache. This stackoverflow thread talks about the problems.
|
| https://stackoverflow.com/questions/10744645/detect-touchpad...
| kyawzazaw wrote:
| I wish I am able to use this in my day to day work.
| victor96 wrote:
| Awesome, let us know how it goes, we're keen for any feedback.
| pbiggar wrote:
| Incidentally, this is how we plan to make darklang's UI work in
| the future (see https://roadmap.darklang.com/editor/canvas.html
| for the similar-ish image).
| victor96 wrote:
| Looks super interesting, giving visuals some structure is super
| helpful especially when you have so much information to
| display. Helps make it navigable/digestable.
| kyawzazaw wrote:
| > Most diagramming tools are generic and flexible for any
| purpose. This is great for quick sketches and whiteboarding but
| painful for creating longer-term documentation where it's
| important for objects to contain metadata and have relationships
| with other objects.
|
| I'd suggest to change this copy writing to "any purpose - which
| is great". Was a bit confused while reading, had a bit of
| disconnect.
| sbuccini wrote:
| This is very interesting. I had never heard of the C4 model
| before and will be using it going forward.
|
| I'm skeptical that the current solution will be completely immune
| from doc rot but it certainly seems like there should be some way
| to generate/validate these diagrams from code. For example, there
| are many natural parallels between the flows diagrammed in your
| tool and setting up user journeys for E2E integration testing.
| JacobShadbolt wrote:
| We're big believers that the C4 model gives a good lightweight
| approach and guidance for those who struggle to articulate the
| complexities of software.
|
| Currently the code checks work through manual set up and won't
| remove all doc rot for sure, but indicates when drift is
| happening. This helps both direct to what code/resources are of
| interest (onboarding new hires), and also checks it still
| exists in the source control. More smarter checks to continue
| removing doc rot are planned.
| gorango wrote:
| Integration with infrastructure-as-code tools would be really
| interesting. Interpolation of standards.
| victor96 wrote:
| What tools would you see IcePanel integrating with?
| gorango wrote:
| terraform, ansible
| eximius wrote:
| Wow! I absolutely love this! I will have to try it! Better C4
| tooling has been something in the back of my mind for a while and
| this looks pretty polished.
|
| I do have some concerns on pricing. $30-40/editor/month is pretty
| steep! Unless there are good tools for managing swapping users in
| and out of "reader" vs "editor" states across billing cycles, I
| think a lot of orgs will balk at this pricing. I know mine will
| if 98% of our ENG team isn't editing except maybe once a year.
| victor96 wrote:
| Awesome, let us know your thoughts/feedback!
|
| We have ideas to increase the capability of readers to make
| edit suggestions, that can be accepted by an editor. This way
| you can have some of the more junior team members included in
| the reader count.
|
| How would this sound for you?
| eximius wrote:
| That's a good start!
|
| Ultimately, I'm not just not sure what the right billing
| model here is. Obviously, I want to pay a "reasonable
| amount", but I understand you need that model to have some
| kind of payment floor. :)
|
| Some major components of usage/pricing that I can think of:
|
| - Domain Owners - some users will be subject matter experts
| or DRIs that have ownership over parts of the overall model.
| These are more likely to be editors, but even other engineers
| may have small tweaks (edit suggestions) for a domain someone
| owns
|
| - Any given engineering user will probably not be editing for
| the vast majority of the time. This + your existing pricing
| model + edit suggestions would lead to "editors" functioning
| more as just "approvers". It pushes an org to have a handful
| of approvers and the rest of their users as commenters.
|
| - high price anchoring - $40/user/month _sounds_ like a lot,
| even if it 's for only a few users. It's also a more
| complicated user model that makes it more difficult to
| integrate into IT organizations. It is easier to integrate
| all users uniformly at a lower price per seat. And if I have
| 10 people on my team, $4/user/month is the same as having one
| editor but far more palatable (to me).
| victor96 wrote:
| Thanks, great points. Especially the last one about it
| being difficult for an org to figure out who should be
| editors/readers/etc. It's definitely a challenge for us
| that we'll need to think more about.
| mattste wrote:
| I came here to echo the pricing sentiment. I just encountered
| this problem and documented my company's architecture using
| Whimsical. I felt it was lacking.
|
| We're a <10 person start-up. $40/mo seems too much relative to
| how often we'd use the tool. I would use this tool if there was
| a cheaper option ($10/mo/editor) for a team of our size.
| FarhadG wrote:
| For those not familiar with C4, this is a great video explaining
| the concepts: https://www.youtube.com/watch?v=x2-rSnhpw0g
| victor96 wrote:
| Great talk by Simon Brown! There's also a similar talk from
| Devoxx a few months ago.
|
| https://www.youtube.com/watch?v=36OTe7LNd6M
| whalesalad wrote:
| Every time I try and use this I get completely overwhelmed by the
| UI. I love the idea of being able to set a mode/scope of editing
| only a small chunk of infra, then exit or zoom out to a higher
| level and glue that block to another block, losing all that high
| resolution while still being able to dive back in and see more
| detail again. But yeah, I have tried a lot of times now to use
| this tool and it is always super overwhelming. I just want to
| draw boxes, enrich them, glue them as needed but this is like a
| whole new IDE and programming environment with lots of specific
| terminology.
| JacobShadbolt wrote:
| Great feedback. Is the C4 model something you had explored
| before? I'm wondering what areas you find most overwhelming as
| the idea of drawing boxes, enriching them is the simplicity
| we're aiming for.
___________________________________________________________________
(page generated 2023-01-11 23:01 UTC)