I'm working at a small company that develops software meant for customers to install and run on their own servers. Our product has been around since the 90s, and as you can imagine, it's pretty legacy! There's currently no API, just a command line app and some in-house scripting, along with basic password authentication through PAM. We're looking to modernize the application with the next version, especially to better fit into the current cloud and Linux ecosystem. I've been finding that most resources out there cater to SaaS vendors who control their environments, which isn't our case. I'm specifically adding an HTTP API and need to support more modern authentication methods, but I don't have control over where our software will be installed. Here are my questions:
1. Which authentication methods should the API support (e.g., OAuth2)?
2. For user authentication on a Linux server, is PAM with password and Kerberos sufficient?
3. Can we expect customers to install additional dependencies alongside our software? (like an RDBMS or message queue)
4. Should we log to the systemd journal?
5. We want to create a container image for easier deployments. What are the best practices for that?
I know this sounds like basic devops stuff, but I'm coming from a background in mainframe and old-school Unix, and my colleagues have decades more experience than I do. Any advice or resources would be greatly appreciated!
1 Answer
When you're tackling big changes in software, especially something over 200,000 lines of code, be cautious. The chances of a total failure go up significantly. But if you're doing incremental improvements and tackling technical debt instead of a complete rewrite, then you should be okay.
As for adding an HTTP API, think about your users. A lot of developers can be very attached to how things are, so make sure you talk to them first. Also, OAuth2 or JWT are solid choices for flexibility in auth.
Regarding external dependencies, using Docker can help. Docker Compose can bundle everything together, so your customers wouldn't have to install an RDBMS or message queue separately unless you want to go that route.
Just so you know, you're not replacing your CLI—it's more of an addition, right? The current product was built for a terminal, and many customers have adapted it, which has potential downsides for attracting new business.