I am writing a distributed computing related paper. I have defined the specification of a service (abstraction) with its functional interface and guarantees. I have provided an algorithm which correctly implements the service and I have provided a proof of correctness for the algorithm. Now, I would like to discuss the real world implementation of the service and propose some optimizations for it. I wonder if I should refer to "the real-world implementation" rather as "the real-world deployment". I'm not sure if there is really a difference between usage of the words "implementation" and "deployment" in this context.
Service realization (implementation of the service description) and service deployment are two phases of a service lifecycle.
Realization focuses on service technical implementation details. In this phase, implementation (coding) of the specification of a service is completed.
Deployment addresses the problem of installing, configuring and managing services and service instances in the service execution environment.
In the context of your question, I would refer to it as a possible optimization of service implementation during the realization phase. The algorithm (or the optimization) can be evaluated after the deployment phase (or after the service was deployed).
Related
I see the term "pure upstream" used a lot describing different software packages/distributions. I get that "upstream" in the context of open source refers to a code base from which a certain software package was forked. But what does it mean to say that a certain software package is "pure upstream"?
I think the “pure” part of "pure upstream" means that the codebase remains unencumbered with changes that are custom changes needed for a particular application use or environment which isn’t applicable to most users. Some projects may want to evolve to become more of a Swiss army knife of an application but some may decide to keep to a small coherent functional space. How purity rules apply is a judgement call for the maintainers of the upstream project.
An example of a non-pure fork could be a proprietary extension that could cause vendor lock-in. Take a look at this article about Kubernetes: https://technative.io/kubernetes-must-stay-pure-upstream-open-source/
I have the following Questions About embedded unit testing:
Can Google unit testing be used for embedded C Code?
Is Google unit test compatible with IEC 62304?
I tried to find a document, which could answer my Question but unable to find that. Even in the Google Unit Test Official Documentation1, I was not able to find the answer. Also, I have the following Question:
How would I know an open source Unit Testing Tool is compatible with IEC 62304 Standard?
Please help me with your Knowledge in Unit Testing.
Thanks in Advance.
To answer your questions directly:
googletest is intended for use with C++. The link in Vertexwahn’s answer shows that at least one person has been able to use it for testing C.
2 & 3. IEC 62304 is a software life cycle process, it has nothing to say about whether you can or cannot use a particular tool, only the steps which you must go through in your project.
Unit testing is certainly one step that you would go through in your software life cycle. As the engineer responsible, it is your job to decide whether or not a tool is suitable for a particular task. No person outside your project can ever tell you that a tool is suitable for use in developing a particular medical device, because this depends very highly not only on the design of the particular device, but also on the testing strategy that your are going to adopt.
The testing strategy in turn will depend on the particular risks that you need to mitigate. You will need to follow ISO 14971 for your risk management process.
At every stage of the process you will have to document the reasons for the decisions that you have made according to an ISO 13485 quality management process.
When you come to make a regulatory submission to an approved body they will appoint an auditor who will look through your documentation. In the vast majority of cases the auditor will have absolutely no technical expertise in software. They will check that you have followed the appropriate documentation process but ultimately they will take your word on whether or not a tool is suitable.
It is easy to trick an auditor and use an unsuitable tool by creating a large volume of paperwork which falsely explains why it is suitable. If you do this no one will know until or unless the medical device causes harm to someone and your company (or you personally) gets sued or prosecuted and the documents get examined by technical experts appointed by a court.
What you need to think about when you put your signature on the document that states the tool is suitable is whether you could stand up in court and defend your decision after someone has been harmed.
After all this, having said that no tool is ever either inherently suitable or unsuitable, there are some software suppliers that make claims of suitability or even "pre-approval". What this means is that they have pre-written many of the documents that your regulatory submission will require. These are always very expensive (nothing free like googletest fits into this category). Even if you use these pre-written documents, it is your responsibility to review them and put your signature against them and say that they are correct and more importantly that they are applicable to your specific project. Buying a product like this saves you time, but not liability.
GoogleTest seems to work with C -> https://meekrosoft.wordpress.com/2009/11/09/unit-testing-c-code-with-the-googletest-framework/
Google will not take over the responsibility for you to be compliant with IEC 62304 regarding your use cases. You have to make sure that the tools you use do what they should do for the use case you use them. For instance, you can come up with an acceptance test for GoogleTest that proves that it works for you as expected.
When doing this consider also known bugs. Even if a company offers you a unit test framework that is IEC 62304 compliant I would ask myself if this test framework has more users and is better tested than gtest.
I think something like this does not exist - it would mean that the Open Source project would take over the liability for damages resulting from its users
We have a requirement of building stateless micro services which rely on a database cluster to persist data.
What is the approach that is recommended for redundant stateless micro services(for high availability and scalability) using the database cluster. For example: Running multiple copies of version 1.0 Payment service.
Should all the redundant micro services use a common shared DB schema or they should have their own schema? In case of independent DB schema inconsistency among the redundant services may exist.
Also how can the schema upgrade handled in case of common DB schema?
This is a super broad topic, and rather hard to answer in general terms.
However...
A key requirement for a micro service architecture is that each service should be independent from the others. You should be able to deploy, modify, improve, scale your micro service independently from the others.
This means you do not want to share anything other than API definitions. You certainly don't want to share a schema; each service should be able to define its own schema, release new versions, change data types etc. without having to check with the other services. That's almost impossible with a shared schema.
You may not want to share a physical server. Sharing a server means you cannot make independent promises on scalability and up-time; a big part of the micro service approach means that the team that builds it is also responsible for running it. You really want to avoid the "well, it worked in dev, so if it doesn't scale on production, it's the operations team's problem" attitude. Databases - especially clustered, redundant databases - can be expensive, so you might compromise on this if you really need this.
As most microservice solutions use containerization and cloud hosting, it's quite unlikely that you'd have the "one database server to rule them all" sitting around. You may find it much better to have each micro service run its own persistence service, rather than sharing.
The common approach to dealing with inconsistencies is to accept them - but to use CQRS to distribute data between microservices, and make sure the micro services deal with their internal consistency requirements.
This also deals with the "should I upgrade my database when I release a new version?" question. If your observers understand the version for each message, they can make decisions on how to store them. For instance, if version 1.0 uses a different set of attributes to version 1.1, the listener can do the mapping.
In the comments, you ask about consistency. This is a super complex topic - especially in micro service architectures.
If you have, for instance, a "customers" service and an "orders" service, you must make sure that all orders have a valid customer. In a monolithic application, with a single database, and exclusively synchronous interactions, that's easy to enforce at the database level.
In a micro service architecture, where you might have lots of data stores, with no dependencies on each other, and a combination of synchronous and asynchronous calls, it's really hard. This is an inevitable side effect of reducing dependencies between micro services.
The most common approach is "eventual consistency". This typically requires a slightly different application design. For instance, on the "orders" screen, you would invoke first the client microservice (to get client data), and then the "orders" service (to get order details), rather than have a single (large) service call to retrieve everything.
I have a question around testing! As of now, I'm in a unique situation where the software I am writing is going out to a third party vendor and storing some data. In this situation, writing a test to confirm that that data is posted successfully means using a production endpoint...which I doubt is a smart way to write things.
In this situation, no one seems to have a good solution for ensuring the endpoint works other then asking the third party for a dummy/test setup. I was wondering if anyone had a better idea of how to perform this sort of interaction. How do you write an efficient contract test when you don't OWN a bit of your codebase?
Please and thank ya :D
There are different alternatives to deal with this situation, depending on the level of collaboration you can get from the third party vendor:
Contract testing:
Pact is a somewhat mature framework that allows you to write unit tests that make HTTP requests against a mock third party provider service, which get persisted into a document (the Pact file) that can be shared with the vendor. If using Pact as well, the vendor can use the Pact file to run the tests against the provider service. The consumer (your service) documents the endpoints used of the provider (the third party service) along with the expected responses, and the provider validates those against itself, ensuring the integration.
For this approach to work, your third party vendor has to be open to fetch your pact file and run your consumer contract tests against their service. Contract testing allows your tests to work totally independent from the provider service, as your service and the provider's service are never connected together while testing.
Record and replay:
The idea behind this approach is to write tests that, in their initial run, make requests against real services and record their responses. The next runs of these tests will not reach real services but instead operate against the recorded responses from the first run. VCR is a good example of a library that enables this kind of testing.
For this approach to work, you don't need any cooperation from the third party vendor. You would make requests to a real service from time to time (to keep your sample responses fresh), which will be subject to availability of the provider service.
Test environment:
As you mentioned in your question, asking for a test environment/account to the provider is also a possibility. With this resource, you could write end to end tests that reach a realistic provider service, as well as having access to the environment itself to make assertions on its state as part of your tests.
The challenge with this approach is around the maintenance of this test environment: how can you be sure its version is the same as the one you are integrating against in production? Who looks after this environment's availability? Who creates data in this environment? Is this data realistic and representative of the real universe?
Semantic monitoring:
A final option would be to write a test that makes a sanity check of the integration between your service and the provider's in the production environment. This test could run after every deployment on your end, or even on a regular basis outside of deployment windows.
For this approach to work you don't need any collaboration from the third party vendor, but this alternative doesn't scale very well if you have a lot of integration use cases, as these tests tend to be slow to run, flaky (as they depend on real networks and systems availability) and pollute real environments. It's better to keep these tests as the very top of the testing pyramid, focused on very critical use cases. Additionally, you won't normally be able to test anything beyond happy paths, as you don't have control of the provider service to set it in any specific state beyond the "normal" one.
Short answer to your question
How do you write an efficient contract test when you don't OWN a bit
of your codebase?
It is not possible without cooperation with the third party. Contract Testing requires both parties (consumer and provider) to adhere to the contract, consumer by leveraging the contract as the API mock or vice versa (leveraging API mock to create contract) and provider to run the contract as a test.
However with third party vendors, a possible option is to request them to share the API Specification such as OpenAPI for their service, which you can leverage to mock their API. In a way you are treating the API Spec itself as the contract to which they may already be adhering.
Here are some tools that can help you mock the third party API if you have their OpenAPI Specification.
Stoplight Prism (API Proxy and mock server)
Wiremock Studio
Specmatic (I am lead dev and CTO at Specmatic)
However the effectiveness of this approach in identifying issues depends on third party vendor API Specification being a reliable representation of their actual implementation among other things.
Is there a benefit for using prebuilt connectors to and from SaaS billing platforms like Aria/Zuora when they live between Salesforce and Netsuite used as pure CRM and ERP/Acounting/Finance respectively. That is, versus using an ESB/Integration platform like Mulesoft or Boomi.
We are currently looking at changing billing and ERP systems and having them integrate together and with Salesforce CRM. So the chain would look like:
CRM -- Billing Solution -- ERP
Many of the billing systems have prebuilt connectors that work with ERP systems like Netsuite or Fusion, as well as connectors for Salesforce. Not to mention web service end points/APIs.
But there are integration vendors like Mulesoft and Boomi (basically Enterprise Service Bus PaaS providers) that also allow integration between the services.
I come from a SOA background and tend to favour a standalone ESB to connect the systems but due to my lack of familiarity with Saas ERP systems don't understand the benefits and pitfalls in the prebuilt connector vs ESB debate. I understand the concepts behind avoiding point to point integration, which would turn around to being a benefit for using ESBs. But is there a benefit for using prebuilt connectors within the SaaS platforms ... and are there serious downsides (my main concern).
Can anyone provide some insight here? I am not asking for "which one is best", just some real world experience good or bad that could help someone make these kinds of decisions.
I cannot provide a comprehensive comparison between the services you plan on using, but your question is quite interesting so I thought I'd share my thoughts and experience and hope you'll benefit from it.
Prebuilt connectors are not something new - they existed long before SaaS and iPaaS became a thing. So their pros and cons are still the same, the main issues you will be looking at are still very much related to the lack of flexibility you'll be facing and of course, the shortcomings of point-to-point integration. Things are somewhat refracted via the prism of SaaS/iPaaS but I believe that most aspects are still relevant.
Prebuilt Connector capabilities and support
You need to assess to what extent a prebuilt connector really covers the integration between the two systems. Services like salesforce take pride in their customizability and extensibility by using 3rd party extensions. In most cases the connector will be following a one-size-fits-all approach that only satisfies the most common and simple of all integration needs. It's all fun and games until something has to change. It is not possible to know in advance what you could need the future but think about it - would you be able to count on having your customisations and extensions covered by the prebuilt connector in case you decide to integrate them as well?
Another point you must consider is support - what happens if one of those companies decide to suddenly announce that they will stop supporting future integration via prebuilt connectors you are already using? You should check to see if there are any guarantees for you.
Tight Coupling and Service provider lock-in
Using point to point connectors will couple systems to each other so you’ll be severely limiting your options to switch between platforms if you need to at some point. It might seem a fairly simple integration scenario now, but adding more systems to the mix over time generally makes things even worse, since you are going to have dependencies here and there, and not every new system will have a connector out of the box to integrate easily with all the others you're already using. Having a middleware gives you the precious ability to map and transform data if needed, and maybe even apply some business logic that makes your life much easier (and cheaper). Also you'd be able to replace a system without having to replace others depending on it.
Consider your scenario: if you decide to change the billing system, you will have to find one that’s being properly supported by both the CRM and ERP providers. Thus, you could potentially remain locked into using exactly these three, even though for example they don’t fit your needs anymore or there is something else on the market that would have given you great competitive advantage if only you could integrate with it.
Orchestration and future investments
An important note about the p-2-p scenario is that you will not be able to implement process services that span across all the systems if needed. The added flexibility and benefits of using even simple forms of orchestration (I’m not even talking about achieving what can be achieved with a full featured business process management) will be off reach for your business. When the market changes and Time to Market is the deciding factor you may be not be prepared.
Thoughts on choosing iPaaS
Using iPaaS platform looks like a much better decision in the long run. Yet, you still have to make sure that the platform does not just give you some set of predefined connectors and drag&drop beauties (they all do), but also the ability to easily implement your very own integrations from scratch while supporting industry standards. I think that it is absolutely crucial to have this kind of flexibility when talking about an ESB solution, be it in the cloud or on premises.
The potential cons of the iPaaS approach would be:
you come to depend on yet another service provider and you will have more costs because the service is not free;
your data travels to another service provider, so there is additional risk in terms of security, no matter what the service providers may try to tell you;
more upfront effort spent on design and implementation;
additional burden, related to having to maintain integration and accommodate potential changes (however rare they might be) if a new version comes out.
Conclusion
It’s all really a tradeoff between desired flexibility and the investment that you’re willing to make. Your decision will heavily depend on the current state of your business and your growth expectations going forward, rather than the purely technical side of things.
I hope my thoughts gave your some perspective. Please update the question with your decision and reasoning when the time comes. Good luck!