Grace Jansen is a developer advocate at IBM, working with Open Liberty and Reactive Platform. She has now been with IBM 18 months, after graduating from Exeter University with a Degree in Biology. Moving to software engineering has been a challenging step for Grace, but she enjoys bringing a varied perspective to her projects and using her knowledge of biological systems to simplify complex software patterns and architectures. As a developer advocate with an interest in reactive architecture, Grace builds POC’s, demos and sample applications, and writes guides and tutorials to help guide users through technologies and products. Grace also has a keen passion for encouraging more women into STEM and especially Technology careers.
We spoke to Grace to learn about her journey from biologist to developer, and took a look at what kind of advice she has for others looking to take a less conventional career transition.
How difficult was the transition from a degree in biology to working in software engineering as a developer advocate?
According to Grace: “I think any transition from one expertise to a different industry and another expertise is always difficult. So yeah, it was really hard at first and it was a super steep learning curve. I was very lucky at University. As part of my biology degree, I actually did programming. So I used Python to program biological models in different biological scenarios. So I was lucky that I had some programming knowledge, and that helped a lot going into it. But I’d never done object orientated. I’d never even heard of Java. So yeah, it was a super steep learning curve.”
When asked about what helped, she explained: “I think the thing that made it easier was having I was very lucky that IBM gave me the time to learn. They gave me the time, the resources and more importantly, the mentors and support. So I really had a community behind me trying to help me get up to speed.”
What can we learn from nature to improve reactive architecture?
Grace brings a plethora of valuable insights from studying nature to the world of computer science. She shared:
“I think we can learn loads from nature. Nature has been evolving in this deliberate process. For millennia, they’ve had so many more years than we have to perfect these kind of processes. And we often want to mimic the same sorts of behaviours. So think about the brain, for example, the brain is this amazingly complex form of data storage, essentially. So there’s currently research going into how can we mimic the way the brain records data and information in the form of chips. So there are new chips that are being created to store data in the same way that brains are to make it more efficient. So it’s not just software, it’s hardware as well.
Thus, Grace believes there are many things we can learn from nature including how to architect your applications better. “So mimicking the behaviour that social structures within nature already do.”
Recommended tools or processes to speed up documenting software
We often as developers what kind of tools and processes they recommend to help less experienced developers who are looking to expand their knowledge and gain new skills. Scientific study typically requires methodical documentation, a practice which can also benefit developers. According to Grace,
“I think it’s really important for you to write notes as you go along. In regards to if you’re trying to implement a certain software or you’re trying to integrate two different programmes together. For example, it’s really important that you record the steps that you’ve taken because looking back without any notes, it can be really hard to remember the small individual problems you might have come up against.”
Thus, having really detailed notes as you go along, might seem tedious at the time, but really helps when you’re writing up documentation not only for yourself but also for others to follow in your footsteps. So they don’t reach the same pitfalls and challenges.
How would you define reactive architecture?
Application requirements have changed dramatically in recent years. Only a few years ago a large application had tens of servers, seconds of response time, hours of offline maintenance and gigabytes of data. Today applications are deployed on everything from mobile devices to cloud-based clusters running thousands of multi-core processors. Users expect millisecond response times and 100% uptime. Data is measured in Petabytes. Today’s demands are simply not met by yesterday’s software architectures.
Reactive architecture as a framework or philosophy is documented in the Reactive Manifesto, a set of specifications that were created in about 2015. Systems built as Reactive Systems are more flexible, loosely-coupled and scalable. This makes them easier to develop and amenable to change. They are significantly more tolerant of failure and when failure does occur they meet it with elegance rather than disaster. Reactive Systems are highly responsive, giving users effective interactive feedback.
Grace defines reactive architecture as “being elastic, being resilient, being reactive, and most importantly, being message-driven underneath all of that. So by combining these four cornerstones, you’re able to create a completely reactive system. I’d say the main challenges are it’s a shift in the way that you have to think about the design process of your application. You’re not only thinking about the individual microservices, you’re not having to think about the data structure and how you can make that more reactive, you’re having to think about the way that the different services within your application communicate, and making sure that’s as resilient and reactive as possible. And you’re having to think about the resources underlying your system:
- Can you make those elastic?
- Can you make them resilient?
- How do you make them more cost-effective?
All of these things are things that you have to consider when you’re implementing a reactive architecture when you’re not trying to make your application as reactive as possible, can be easy to cut corners, and it can be easy to choose the easy way out, which doesn’t necessarily make for the best user interaction with your system. So it’s really important for you to think about the entire system as a whole to be able to make it true to reactive.”
