Friday, 26 February 2021

How can I manage HTTPS certificates with Kubernetes Ingress and Traffic Parrot?

Kubernetes Ingress is often used to expose HTTPS services outside the cluster. There are several options available for managing HTTPS certificates, which are described below.

Option A - Certificates only in Ingress

  • Use TP HTTP for both HTTP and HTTPS use cases
  • Ingress manages all HTTPS certificates
  • Ingress does all TLS offloading
  • Ingress can have different HTTPS certificates per hostname
  • TP only receives HTTP requests never HTTPS

Option B - Certificates only in TP

  • Use TP HTTP for HTTP use cases
  • Use TP HTTPS for HTTPS use cases
  • Ingress passes through HTTPS connections to TP HTTPS backend using SNI TLS proxy via SNI hostname
  • TP manages all HTTPS certificates
  • TP receives HTTPS requests
  • TP does all TLS offloading
  • Requires compatible HTTPS clients that support client SNI (e.g. not supported in Java 6)
  • Ingress performance overhead incurred due to ingress SNI TLS proxy

Option C - Certificates in both Ingress and TP

  • Use TP HTTP for HTTP use cases
  • Use TP HTTPS for HTTPS use cases
  • Ingress does TLS offloading for original request from the client
  • Ingress has a copy of the certificates used by the client
  • Ingress initiates new HTTPS connection to TP HTTPS backend with client certificates
  • TP receives HTTPS requests
  • TP does TLS offloading for the request from the ingress controller
  • Ingress performance overhead incurred due to initiating new connection with client certificates
  • Maintenance overhead incurred, end users now need to provide the client certificates too

Summary

If the same HTTPS certificates are used globally then Option A is the simplest.

If certificates are per virtual service then Option B is preferable over Option C, unless you are using HTTPS clients that do not support SNI, in which case Option C could be used instead.

You may prefer Option A over both Option B and C for certificates per virtual service if you would like HTTPS to be managed fully by Ingress instead of TP. Option A is the simplest infrastructure but means there are two configuration points: TP for the HTTP virtual service configuration and Ingress for the HTTPS certificate configuration.

Monday, 8 February 2021

How can I expose Traffic Parrot virtual services outside my Kubernetes cluster?

When hosting Traffic Parrot virtual services in a Kubernetes cluster, sometimes access to the virtual services is required from traffic outside of the Kubernetes cluster. In these cases, it is typical to use Kubernetes Ingress alongside a DNS name server to provide access to the services inside the cluster. Here are two common options used to achieve this.

Option A - Static domain with unique Ingress path mappings

  • DNS server points static domain record to static Ingress controller IP
  • Unique paths are used to identify a unique backend service port
  • Ingress rules use the path prefix to route to a backend service port
  • Example
    • trafficparrot.xyz.com points to Ingress controller IP 1.2.3.4 using static DNS entry
    • trafficparrot.xyz.com/service1/http Ingress path prefix maps to backend service1 port 1234
    • trafficparrot.xyz.com/service1/https Ingress path prefix maps to backend service1 port 4567
    • trafficparrot.xyz.com/service2/http Ingress path prefix maps to backend service2 port 1234
    • https://kubernetes.io/docs/concepts/services-networking/ingress/#simple-fanout

Option B - Wildcard domain with unique Ingress host mappings

  • DNS server points wildcard domain record to static Ingress controller IP
  • Unique domain names are used to identify a unique backend service port
  • Ingress rules use the host field to route to a backend service port
  • Example

Monday, 1 February 2021

Traffic Parrot 5.23.0 released, what's new?

We have just released version 5.23.0. Here is a list of the changes that came with the release:

Features

  • Initial release of Traffic Parrot workstation client (beta):
    • The workstation (beta) is part of a new client-server product offering for customers
    • Traffic Parrot workstation clients create virtual services and save configuration files
    • Traffic Parrot servers run virtual services using the configuration files created by the clients
    • Configuration files can be stored and retrieved from version control systems or artifact repositories
  • Initial support for using multiple HTTP/HTTPS ports linked to separate mappings (beta):
    • New virtual services (beta) page to view/add/edit/delete virtual services
    • A distinct HTTP/HTTPS port may be assigned per virtual service
    • Only one virtual service can be edited at a time by selecting from the dropdown
    • The home page now lists all virtual service names and ports
    • Configuration is currently stored in scenarios/VirtualServiceName/service.properties directory structure
    • Increasing the number of virtual services will have a direct impact on memory usage of the server
    • Consider increasing your jvm.args configuration heap size -Xmx128m if you plan to use multiple virtual services per Traffic Parrot instance
  • New arithmetic operations in dynamic responses

Fixes

  • Fixed an issue where the navigation bar overlapped the main content on some smaller screen sizes
  • Fixed an issue where transformer names would be duplicated in mapping files on save

Changes

  • The scenarios feature is being renamed to virtual services (beta)
  • The API /api/scenarios/* is deprecated and will be renamed to /api/virtualServices/* in a future release
  • The scenarios directory is deprecated and will be renamed to to virtual-services in a future release

Friday, 6 November 2020

Data integrity when using API mocks or service virtualization in shared environments

Our customers find that using API mocking or service virtualization in a shared test environment comes with a task of managing potential data integrity issues between the System Under Test and backend or third party databases. Please find below a set of diagrams highlighting different categories of approaches along with their tradeoffs. 

These diagrams highlight categories of solutions. The details will be heavily dependent on customer's use case.















Tuesday, 3 November 2020

Four categories of deployment options when using API mocking or service virtualization

Our customers typically see four categories of deployments when developing or testing software in shared test environments.

Please find below a high-level introduction to the example of a roadmap to removing back-end and third-party dependencies - these diagrams highlight categories of solutions. The details will be heavily dependent on customer's use case. Please contact support@trafficparrot.com, and we can advise on a recommended architecture for your specific needs based on our other customers' experience.


No mocking or service virtualizartion











Friday, 23 October 2020

Can I use Traffic Parrot over VPN?

"Our offshore developers will be using Traffic Parrot. Can you please clarify how that will impact the number of parallel licenses used? If a VPN connection is terminated, the license should stop being used?" - Software Developer working for a global financial institution.

We understand you wanted to know if a Traffic Parrot (TP) license will be checked back into the licensing server pool if the connection is dropped (for example when a VPN connection is closed).

The answer is yes. If the person was running TP outside via VPN connection and the discontinued VPN connection results in the lack of connectivity to the licensing server, the TP license server will recognise a timeout and will check back the license into the pool after the configurable timeout passes. The TP instance without the connection will shut down and the developer will not be able to use it.

If however, the developer was using VPN to access a development machine inside the organization then the connection would not be terminated, and the TP license would be still checked out by the TP instance running on the VM.

Please find the sample diagrams below. 





Monday, 19 October 2020

Traffic Parrot 5.22.0 released, what's new?

We have just released version 5.22.0. Here is a list of the changes that came with the release:

Features

  • Made mapping name editable in the UI for all mapping types

Fixes

  • Ensure internal server errors log the full stack trace

Changes

  • Native IBM® MQ connections will now warn once in the logs the first time that a connection is shared between multiple threads, which can degrade performance. The mapping fields receiveThreads and sendThreads control the number of threads per queue. The ibm-mq-connections.json configuration controls the total readConnectionsToOpen and writeConnectionsToOpen per queue manager.

Sunday, 11 October 2020

Traffic Parrot 5.21.6 released, what's new?

We have just released version 5.21.6. Here is a list of the changes that came with the release:

Features

  • New property trafficparrot.virtualservice.http.monitorPerformance can be used to enable HTTP response timings in the logs:
    2020-10-07 20:09:32,330 INFO  Request to 'GET /test123' was received on '2020-10-07T19:09:32.326Z' from '127.0.0.1'. Response was sent on '2020-10-07T19:09:32.397Z' to '127.0.0.1'. Total processing time 71ms
  • Added new PassthroughMessage MQ proxy example to the SDK workspace

Fixes

  • Fixed support for OpenAPI array examples specified as a comma separated string
  • Ensure startup error causes are recorded in the logs

Changes

  • Upgraded bundled JRE from 8u262 to 8u265
  • Display system tray in a background thread to improve startup times on some systems
  • Valid JSON bodies in mapping files will be persisted as inline JSON rather than an escaped string

Friday, 25 September 2020

Traffic Parrot 5.20.2 released, what's new?

We have just released version 5.20.2. Here is a list of the changes that came with the release:

Features

  • Mappings list user interface improvements for all protocols:
    • Added support for customizing which columns are displayed in the mappings list in the UI. The selected settings are stored in the browser to allow different Traffic Parrot users to set different preferences.
    • Edit mapping tags that can be used to organize and search mappings
    • Added new tags column which is hidden by default
    • Display mapping file name when editing a mapping
  • Added mapping file name to the logs when reporting request match status for MQ/JMS/Files mappings

Fixes

  • Switching scenario with mappings caches enabled now resets the caches
  • Traffic Parrot now shuts down gracefully on Windows when the stop script is run
  • Fixed an issue where the HTTP virtual service would not respond if a mapping file was deleted while the request was being served

Monday, 21 September 2020

A global retail bank has migrated one of their departments off CA Lisa and now saves 51% on tool costs per year

In September 2020, after a thorough evaluation, a global retail bank selected Traffic Parrot for their application testing needs. They have used WireMock for HTTP service virtualization needs and Traffic Parrot for IBM® MQ in both their performance testing and system testing environments.

"We have migrated our department off CA Lisa to reduce our operational costs in performance and system testing environments. We used Wiremock for HTTP stubbing and mocking and Traffic Parrot for IBM MQ. Neither Wiremock nor Traffic Parrot provides all the features available in CA Lisa. Still, after initial proof of concept assessment, we have decided those tools feature sets will be sufficient for our needs and significantly cut costs. It took our team six months to migrate HTTP to Wiremock and another three months working closely with the Traffic Parrot team to improve their offering to meet our load testing and mainframe integration requirements. With this investment, we cut our tooling costs in half."

​ Executive working for a  global retail bank.

Next steps

Please contact sales@trafficparrot.com or call +44 20 3239 7753 (available 9am to 5pm United Kingdom time) for more details on how we can help your team save on service virtualization costs.

Monday, 14 September 2020

Traffic Parrot 5.19.4 released, what's new?

  We have just released version 5.19.4. Here is a list of the changes that came with the release:

Features

  • Added support for configuring gRPC delays via fixedDelayMilliseconds or distributionDelay in the mapping files
  • Exposed new properties for tuning gRPC performance:
    • trafficparrot.virtualservice.grpc.server.receiveThreads=DOUBLE_NUMBER_OF_PROCESSORS
    • trafficparrot.virtualservice.grpc.server.sendThreads=DOUBLE_NUMBER_OF_PROCESSORS
    • trafficparrot.virtualservice.grpc.server.replay.maxMessagesWaitingToBeSent=1000

Fixes

  • Traffic Parrot now shuts down gracefully when the launcher process is killed (e.g. during a docker stop)

Changes

  • Only consider TCP ports when printing diagnostic information when there is a port clash on startup

Saturday, 5 September 2020

Traffic Parrot 5.18.0 released, whats new?

  We have just released version 5.18.0. Here is a list of the changes that came with the release:

Features

Fixes

  • Fixes to the gRPC mappings list editing and search mechanism
  • Fixed a bug where the edit modal would incorrectly close automatically if closed and reopened too quickly
  • Fixed a bug where the edit modal would show the previous flash message if closed and reopened too quickly
  • Fixes for JMS java.io.Serializable object support
  • Fixes for port in use diagnostic message when multiple PIDs are involved

Changes

  • The property trafficparrotserver.log4j.properties.filename has been replaced by trafficparrotserver.logging.properties.filename.
  • Logging properties file names indicate which type of logging configuration to use:
    • Names like *.log4j.* are assumed to be Log4j version 1 configuration
    • Names like *.log4j2.* are assumed to be Log4j version 2 configuration
  • The MQ message putDateTime log line now has a millisecond (instead of second) resolution to help investigate performance issues when working with Native IBM MQ
  • Upgraded commons-codec to 1.13 from 1.11
  • Upgraded commons-lang3 from 3.8.1 to 3.11
  • Upgraded commons-io from 2.6 to 2.7
  • Upgraded gson from 2.8.6 to 2.8.7

Wednesday, 26 August 2020

How many licenses do I need to purchase for 10 users in a shared QA environment?

"At the beginning, we would have about 10 users that would use Traffic Parrot in a shared QA environment, possibly all at the same time. Can they all use the same instance over the web application user interface of Traffic Parrot? How many licenses would I need to purchase in this case?" - Software Architect working for an E-commerce company.

Please have a look at a definition of how Traffic Parrot (TP) licensing works: What is the "concurrent floating license"?

An instance is a process that may run on a server or a laptop. Every instance you need to run in parallel (at the same time) needs a license.

As teams and test environments scale in size, our customers find that using multiple licenses reduces risk and increases testing throughput (test turnaround time).

Our customers have found that teams that are working on different subsystems or projects or a collection of related features are best served by having their own license per environment. If multiple teams or initiatives are working on the same shared environment then we recommend using one TP instance per third party and backend service in each environment.

In addition, if your developers are using TP on a laptop you can start to run into contention issues after three or four developers using it to debug virtual services at the same time before commits, two developers intensive use can benefit from their own licenses.

These guidelines will minimize the complexity of your virtual services, both for initial use and during their subsequent maintenance while running TP in shared environments such as QA or SIT. 

Performance testing may require high core count machines or multiple load-balanced instances.

We would be happy to schedule a call at your convenience to discuss this, please contact sales@trafficparrot.com to schedule a call to discuss your requirements.

Wednesday, 19 August 2020

Why would I need multiple floating licenses?

 "Why would I need multiple floating licenses?" - Software Developer working for an E-commerce company.

Here is how TP (Traffic Parrot) licensing works: http://blog.trafficparrot.com/2020/04/what-is-concurrent-floating-license.html 

If you want to run more than one TP process in parallel in different places you will need more than one license, one for each process.

Monday, 10 August 2020

Traffic Parrot 5.16.0 released, whats new?

 We have just released version 5.16.0. Here is a list of the changes that came with the release:

Features

  • Select handlebars helper CSV file caching. When you set
    trafficparrot.virtualservice.handlebars.select.indexAndCacheCsvFiles=true
    the CSV file loading performance will be significantly improved.
  • Supporting large number of CPU cores. When you run Traffic Parrot on many cores (40 or more) it would fail to start and report an error
    javax.servlet.ServletException: java.lang.IllegalStateException: Insufficient configured threads: required=212 < max=200 for QueuedThreadPool[qtp318353283]@12f9af83{STARTED,8<=168<=200,i=0,r=20,q=0}[ReservedThreadExecutor@71b3bc45{s=0/20,p=0}]
    The fix is to increase the number of threads Jetty can spin up. This was done by exposing two properties to configure HTTP Jetty server thread queues:
    trafficparrot.gui.http.queuedThreadPool.maxThreads=200
    trafficparrot.gui.http.queuedThreadPool.minThreads=8

Changes

  • Performance improvements to dynamic responses
  • Jetty HTTP Server upgrade from 9.4.20.v20190813 to 9.4.30.v20200611
  • Upgraded Wiremock from 2.25.1 to 2.27.1
  • Upgraded Http client from 2.6.2 to 2.7.0
  • Several other library version upgrades